Разработка информационной системы “Склад”

 

• Количество  уровней дерева:

            r=5

• Количество диаграмм на уровнях:

            S₁=1; S₂=1; S₃=2; S₄=4; S₅=8

• Количество функциональных блоков в j-й диаграмме на i-м уровне(n_ij):

            n₁₁=1; n₁₂=2; n₁₃=4; n₁₄=8; n₁₅=16

• Число стрелок у каждого блока: a₁=4; a₂=4; a₃=4; a₄=4; a₅=4; a₆=4; a₇=4; a₈=4; a₉=4; a₁₀=4; a₁₁=4; a₁₂=4; a₁₃=4; a₁₄=4; a₁₅=4; a₁₆=4; a₁₇=4; a₁₈=4; a₁₈=4; a₁₉=4; a₂₀=4; a₂₁=4; a₂₂=4; a₂₃=4; a₂₄=4; a₂₅=4; a₂₆=4; a₂₇=4; a₂₈=4; a₂₉=4; a₃₀=4; a₃₁=4;

 

2. Средние характеристики:

 

Количество  диаграмм на уровне:

      

Количество  ФБ на диаграмме:

      

Количество  стрелок в ФБ:

      

      c)  Производные средние характеристики: 

Среднее число  ФБ на уровне:

      

Среднее число  стрелок в диаграмме:

      

Среднее число  стрелок на уровне:

 

Среднее число  элементов на уровне:

                    

Среднее число  элементов на диаграмме:

                      

4) Наша модель:

 

1. Количественный  метод оценки ФМ:

 

• Количество  уровней дерева:    r=5
• Количество диаграмм на уровнях: S₁=1; S₂=1; S₃=1; S₄=1; S₅=1
• Количество функциональных блоков в j-й диаграмме на i-м уровне(n_ij):

            n₁₁=1; n₁₂=3; n₁₃=2; n₁₄=3; n₁₅=3

• Число стрелок у каждого блока:

            a₁=8; a₂=6; a₃=4; a₄=3; a₅=6; a₆=3; a₇=5; a₈=5; a₉=5; a₁₀=5; a₁₁=5; a₁₂=5;

 

2. Средние характеристики:

 

Количество  диаграмм на уровне:

      

Количество  ФБ на диаграмме:

      

Количество  стрелок в ФБ:

      

       с) Производные средние характеристики: 

Среднее число  ФБ на уровне:

      

Среднее число  стрелок в диаграмме:

      

Среднее число  стрелок на уровне:

 

Среднее число  элементов на уровне:

                    

Среднее число  элементов на диаграмме:

                    

Анализ используемых стрелок: 

а_с-количество стрелок;

а_с =22 

k₁ -коэффициент связности модели;

   

a_T-количество тунельных стрелок;

a_T=2

k₂- коэффициент глубины проработки ФМ =  
 

Сводная таблица расчета оценки ФМ: 

 
 

График расчета оценки ФМ:  

 
 
 
 

Выводы  по произведенному анализу: 

     Коэффициент связанности k₁, равный 0,63, стремится к 1, это говорит о том, что связанность в функциональной модели хорошая. 

     Коэффициент глубины проработки k₂, равный 0,09, не стремится у 0, но и не стремится к 1. Это говорит о средней глубине проработки функциональной модели. Такой результат получился ввиду небольшого количества «туннельных» стрелок по сравнению с обыкновенными стрелками ФМ. 
 

Получив два коэффициента k₁ и k₂, можно построить график: 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

РАЗДЕЛ 3. МОДЕЛИ ДАННЫХ ИНФОРМАЦИОННОЙ СИСТЕМЫ 
 
 

    В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:

1) аспект структуры: методы описания типов и логических структур данных;

2) аспект  манипуляции: методы манипулирования  данными;

3) аспект  целостности: методы описания  и поддержки целостности базы  данных.

Аспект структуры определяет, что из себя логически представляет база данных, аспект целостности определяет средства описаний корректных состояний базы данных, аспект манипуляции определяет способы перехода между состояниями базы данных и способы извлечения данных из базы данных.

   Модель данных - это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы - поведение данных. Таким образом, каждая СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.

   Модель данных строилась при помощи case-средства ERWin автоматизирующего и обеспечивающего высокую эффективность разработки модели данных по методологии IDEF1Х.

    Цель моделирования данных состоит в обеспечении разработчика ИС схемой БД. Схема может состоять из одной или нескольких моделей. Наиболее распространенным способом моделирования данных является подход с использованием диаграмм «сущность-связь» (ERD), ориентированных на разработку реляционных БД. Существует несколько методов построения ERD, различающихся нотацией, описательными возможностями и функциональным предназначением. Построение ERD производилось методом IDEF1Х.

Основными элементами диаграмм «сущность-связь» являются:

1. Сущности;
2. Свойства сущностей (атрибуты);
3. Отношения (связи) между сущностями;

В общем  случае разработка модели по IDEF1Х включает следующие шаги:

• Определяются и детализируются цели проекта, составляется план сбора информации, необходимой для модели;
• Выявляются и описываются основные сущности;
• Выявляются и описываются основные отношения, отображаются на концептуальном уровне (наименее детальном уровне модели);
• Раскрываются нестандартные отношения (типа «многие ко многим»), определяются ключевые и наиболее важные с функциональной точки зрения атрибуты сущностей; данная информация отображается на логическом уровне модели;
• Полностью отображаются все атрибуты сущностей, все элементы модели получают непротиворечивые физические имена; получаемый в результате физический уровень модели может быть отображен в РБД с точно соответствующей ему структурой.

 
 
 
 
 
 

3.1. ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ В 3НФ ИЗ ERWIN: 
 

    Третья нормальная форма (3NF) — одна из возможных нормальных форм таблицы реляционной базы данных. Третья нормальная форма является достаточной при решении большинства практических задач, и процесс проектирования реляционной базы данных, как правило, заканчивается приведением к ней.

    Таблица находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме (2NF) и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK) (иначе говоря, один факт хранится в одном месте).

    Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A - набор ключевых атрибутов (ключ), B и С - различные множества неключевых атрибутов.

На рис.7. представлена логическая модель данных разрабатываемой ИС, построенная по методологии IDEF1Х при помощи case-средства ERWin. 

 
 
 

Рис.7. Логическая модель данных 
 
 
 
 
 
 
 

3.2 ВЫБОР И ОБОСНОВАНИЕ  СУБД: 

     В качестве языка запросов к БД выберем наиболее популярный в настоящее время язык SQL. Для начала расскажем о самом языке SQL, его истории возникновения, преимуществах и недостатках. Затем рассмотрим выбранную СУБД (Система управления базами данных) SQL Server 2005 от компании Microsoft.

     Благодаря применению СУБД появляется  возможность включать правила  управления данными непосредственно в состав средств, обеспечивающих целостность всей системы. При проектировании реляционной СУБД, как и при решении большинства других практических задач, важно учитывать каждый нюанс. Чтобы создать действительно эффективную БД недостаточно организовывать хранение данных в таблицах. При определении данных, хранящихся в БД, применяется тип, как и в большинстве других вариантов среды программирования. Тип данных должен в определенной степени учитываться при осуществлении большинства действий, связанных с эксплуатацией программного обеспечения SQL Server.

    Microsoft SQL Server 2000 – это законченное предложение в области БД и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. 

Преимущества SQL: 

Независимость от конкретной СУБД:

Несмотря  на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально закладывались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle, так и с Microsoft SQL Server и IBM DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно.