Разработка ИС торогового предприятия

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный_номер, Номер койки, Фамилия,

         Имя, Отчество, Адрес, Дата рождения, Пол)

Лечащий_врач [Врач 1, Пациент M]

             (Номер_врача, Регистрационный_номер)

Консультант [Врач M,Пациент N]

            (Номер_врача, Регистрационный_номер). 

Для примера ER-диаграмма  базы данных "Питание" показана на рис.  а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид)

Продукты (ПР, Продукт, Калорийность)

Поставщики (ПОС, Город, Поставщик) [Город]

Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))

Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг))

Города (Город, Страна)

Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Дата_Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и  Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты. 

Существует  ещё наиболее распространенная модификация ER-диаграмм для представления инфологической модели баз данных - "Таблица-связь", пример использования которого приведен на рис. 16. В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени и типа сущности. Строки таблицы – это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, располагаются рядом и обводятся рамкой. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих. Именно этот тип диаграмм будет использоваться при построении инфологической модели базы данных, разрабатываемой в данной дипломной работе.

3. Даталогическая  модель данных

Описание, создаваемое по инфологической модели данных, называют даталогической моделью данных. Даталогическая модель отражает логические связи между элементами данных   вне зависимости от их содержания и среды хранения. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области. Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели, в то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки инфологической модели. Даталогическая модель отображается в физическую память, такую, как диск, лента или какой-либо другой носитель информации. Даталогическая модель в основном используется прикладными программистами для реализации требований, которые выдвинули конечные пользователи, отражённых в инфологической концептуальной модели.

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

При разработке даталогической модели, кроме требований предъявляемых для построения инфологической модели, предъявляются дополнительные требования:

• Загруженные в базу данных корректные данные должны оставаться корректными.
• Данные до включения в базу данных должны проверяться на достоверность.
• Доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями.
• Разрешение проблем, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
• Способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

4. Переход от ER – модели к реляционной.

Переход от инфологической модели “сущность-связь”- это сравнительно простая задача, поскольку в терминологии и принципах ER-модели и реляционного подхода  имеется взаимно однозначное  соответствие. Существует ряд хорошо зарекомендовавших себя правил с пощью которых из ER-диаграмм отроются реляционные таблицы.

1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа: все подтипы в одной таблице (а) или для каждого подтипа - отдельная таблица (б). При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется, по крайней мере, один столбец, содержащий код ТИПА; он становится частью первичного ключа. При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).
7. Имеется два способа работы при наличии исключающих связей: общий столбец и явные внешние ключи (б). Если остающиеся внешние ключи все в одном домене, т.е. имеют общий формат (способ (а)), то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей, покрываемых дугой исключения. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи. Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределенные значения.

5. Физическая модель данных

Физическая  модель данных – модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы.

Внешние модели (даталогические модели) никак  не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.

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

Физическая  модель данных является полностью компьютерно-ориентированной  и конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность. Эти и множество других функций по методам доступа и поддержании баз данных на внешних носителях, а также способов поиска и доступа к данным в современных СУБД обеспечивается в основном ядром базы данных, что значительно облегчает задачу создания БД и их ведение.

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

6. Этапы проектирования базы данных

Этапы проектирования базы данных с учетом рассмотренных выше аспектов:

1. Проектирование инфологической концептуальной модели баз данных:

а) Исследование предметной области применения и  выявление требований конечных пользователей  и решаемых задач.

в) Анализ данных: сбор основных данных (объекты, связи между объектами).

с) Построение ER-диаграммы базы данных.

2. Проектирование даталогической модели базы данных (учитывать требования СУБД ).

a) Потенциально  возможные прикладные программы:  сбор информации о потенциальных возможностях использования данных.

3. Проектирование физической модели базы данных (оценка эксплуатационных характеристик прикладных программ).
4. Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).

 

По этой схеме производилась реализация базы данных “Деканат”, являющейся конечной целью данной дипломной работы. 
 
 
 

10. Практическая  часть

1. Предметная  область и задачи, возложенные на базу данных

База  данных предназначена для хранения данных об обучающихся студентах, а также оценок успеваемости по списку изучаемых дисциплин (программе обучения). Подразумевается, что эта информация может изменятся в течении всего периода обучения и может быть затребована в любое время за период обучения студента и даже после окончания его обучения или участвовать в формировании статистических данных о группе или курсе за любой временной промежуток. База данных несомненно носит характер фактографической информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются работники деканатов, которые относятся к категории пользователей не искушенных в вопросах ведения, администрирования баз данных и поддержании их в актуальном состоянии. Это накладывает определенные требования на разработку системы управления базой данных, при которой все методы доступа, поиска и большинство функций администрирования скрыты внутри программы и прозрачны при работе что, несомненно, скажется на разработке программного интерфейса. Кроме того, существующая на данный момент в деканатах факультетов база данных по делам студентов, диктует необходимость принимать во внимание вопросы совместимости и конвертирования данных существующей базы данных в формат разрабатываемой в данной дипломной работе. Более подробно все требования перечислены ниже:

1. Предоставление общей информации об обучающихся студентах. Это совокупность сведений о каждом студенте обучающегося в данный момент, включает в себя общую информацию такую как фамилия, имя, отчество, дата рождения и поступления, пол, национальность, адрес проживания, семейное положение и состав семьи, а также информацию учебного характера, такую как текущий курс, группа, подгруппа, изучаемый язык,  специализация и др. Подразумевается, что информация будет изменятся и пополнятся в течении срока обучения.
2. Ведение архива студентов. После окончания срока обучения информация о студентах может еще некоторое время быть необходимой (в бумажных архивах университета она хранится в течении 75 лет), поэтому необходимо чтобы студены окончившие обучение заносились в архив и хранились в нем в плоть до принятия решения об их удалении.
3. Пополнение списка поступившими абитуриентами. В начале каждого учебного года в базу данных должны заноситься студенты из числа абитуриентов поступивших в текущем году.
4. Перевод факультета на следующий курс. После окончания учебного года информация о текущем курсе каждого студента должна быть изменена т.е. студент дожен быть переведен на следующий курс в случае успешного завершения сессии. Эти изменения должны затрагивать только личностей из действительного числа студентов и не касаться находящихся в архиве. Кроме того, студенты считающиеся окончившими обучения должны быть автоматически занесены в архив.
5. Распределение групп по специальностям. С этой задачей сталкиваются после сдачи госэкзамена на 3 курсе, когда уже сформированные группы вновь перераспределяются в зависимости от выбранной студентами специальности.
6. Распределения языка по группам. На первом курсе распределение студентов по группам ведется в зависимости от изучаемого иностранного языка.
7. Предоставление А/О и возврат из А/О. В течении обучения студенту может быть предоставлен академический отпуск на один год по его окончанию студент продолжает обучение. В течение этого времени информация о студенте должна храниться в архиве, чтобы быть востребованной при восстановлении. Кроме того иногда требуется информация о дате ухода студента в академический отпуск и номере приказа по которому академический отпуск был предоставлен.
8. Отчисление и восстановление. На любом курсе студент может быть отчислен по ряду причин. Однако факт отчисления не носит фатальный характер и в ряде случаев у него есть возможность восстановиться. Т.о. вплоть до факта восстановления информация должна храниться в архиве пока не будет востребованной или не будет принято решение о нецелесообразности ее хранения. В случае отчисления также требуется информация о дате отчисления студента и номере приказа по которому отчисление произошло.
9. Перевод в другую группу/подгруппу. Эта задача часто имеет место на первом курсе когда студенты изъявляют желание перейти в другую группу или подгруппу когда окончательный состав группы еще полностью не сформировался.
10. Предоставление информации об учебном плане. Дисциплины по которым производится обучение в группах в общеобразовательный период и после выбора специализации должны быть точно представленны. По ним ведутся ведомости об итогах сессии для каждого студента.
11. Ведение информации об итогах сессии и проводимых аттестаций. В период обучения каждый студент изучает дисциплины указанные в учебном плане и, следовательно должен проходить контроль знаний по ним в конце каждого семестра. Кроме того, в середине семестра производится дополнительный контроль знаний по системе отличающегося от экзаменационного.
12. Получение статистической информации о факультете. Для анализа, планирования и принятия решений о дальнейшем развитии факультета полезно иметь информацию представленную в обобщенном виде (итоговых сумм, таблиц, графиков), которую можно извлечь из информации об итогах проведенных сессий, аттестаций и т.д.(количественная и качественная успеваемость, количество задолжников по предметам, количество сдавших экзамены и т.д.).