Проектирование базы данных для коммерческого предприятия

Размещено на http://www.allbest.ru/

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

«Ярославский государственный университет имени П.Г. Демидова»

Университетский колледж

Проектирование базы данных для коммерческого предприятия

Ярославль 2007

Реферат

86 страниц, 1 таблица, 8 схем, 7 рисунков, 11 источников информации, 2 приложения.

Ключевые слова: базы данных, разработка, программирование, среда Delphi, инфологическое моделирование, объект, нормализация, язык SQL, визуальные компоненты, модели данных, склад.

Объект исследования: Borland Delphi 7 как средство разработки баз данных, проектирование и моделирование баз данных, проектирование баз данных по предметной области «Склад».

Цель работы: разработка программного обеспечения для автоматизации учета продукции на складе - базу данных, реализующую хранение данных, организацию доступа к ним и редактирование.

Основные задачи:

Собрать информацию по видам товаров на складе предприятия;

Изучить среду разработки приложений Borland Delphi 7;

Разработать программное обеспечение для учета продукции на складе.

Основные результаты:

Создано программное обеспечение “Магазин автозапчастей”;

Программное обеспечение внедрено для использования на предприятии ООО «_______».

программный delphi масштабируемый

Содержание

Реферат

Содержание

Введение

Глава 1. Области применения баз данных

1.1 Новые тенденции развития СУБД и областей их применения

1.2 Новые области применения баз данных

Глава 2. Базы данных

2.1 Классификация баз данных

2.2 Структурные элементы базы данных

2.3 Понятие информационного объекта

2.4 Нормализация отношений

2.5 Типы связей

Глава 3. Модели данных

3.1 Сведенья о моделях данных

3.2 Виды моделей данных

3.3 Проектирование модели данных

3.4 Представление данных с помощью модели «сущность-связь»

Глава 4. Создание базы данных

4.1 Определение модели данных

4.2 Инфологическое моделирование предметной области

Глава 5. Среда Delphi как средство для разработки СУБД

5.1 Программный продукт Delphi

5.2 Мощный объектно-ориентированный язык

5.3 Объектно-ориентированная модель программных компонент

5.4 Библиотека визуальных компонент

5.5 Формы, модули и метод разработки "Two-Way Tools"

5.6 Масштабируемые средства для построения баз данных

5.7 Настраиваемая среда разработчика

Глава 6. Язык SQL

Глава 7. База данных «Магазин автозапчастей»

7.1 Исходные данные на проектирование

7.2 Реализация проекта

Заключение

Библиографический список

Приложения

Введение

Современная жизнь немыслима без эффективного управления. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия или учреждения. Такая система должна:

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

обеспечивать получение информации, критической по времени, без существенных задержек;

выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

Глава 1. Области применения баз данных

1.1 Новые тенденции развития СУБД и областей их применения

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

В толковом словаре по вычислительной технике, выпущенном в 2002 г., приводится такое определение системы управления базами данных (database management system): "приложение, обеспечивающее создание, хранение, обновление и поиск информации в базе данных, а также управление безопасностью и целостностью данных". В целом это толкование было верно и 30 лет назад, но все же содержательная часть СУБД сейчас совсем иная, чем в те далекие времена (отметим, что в определении уже отсутствует дополнительная фраза, которая использовалась для уточнения понятия еще восемь лет назад, -- "программная оболочка, находящаяся между базой данных и пользователем").

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

В этой ситуации стоит обратить внимание на изменение содержания "платформа Microsoft". Традиционно под этим термином подразумевалась операционная система, Windows. Однако применительно к серверной платформе все чаще мы встречаем связку Windows Server + SQL Server. Более того, представляется вполне реальным, что с выходом в начале следующего года новой версии Microsoft SQL Server (рабочее название Yukon) мы столкнемся с ситуацией, когда все остальные продукты Microsoft будут уже писаться не под Windows, а под Yukon. Хотя существуют и будут существовать настольные базы данных: как ни странно, но Microsoft Access судя по тому как его представляет Microsoft -- это тоже СУБД.

Исторически системы управления базами данных ориентировались на решение задач, связанных в первую очередь с транзакционной обработкой структурированной информации. Безусловно, наилучшим, проверенным временем решением здесь была и остается реляционная модель СУБД. Однако в последние годы область применения баз данных неизменно расширялась. С одной стороны, нужно управлять более широким набором форматов данных, переходя к решению общих проблем управления корпоративной информацией. С другой -- именно СУБД берут на себя основные функции интеграции данных и приложений корпоративных систем. (По данным Gartner Group, информационные отделы предприятий расходуют до 40% своего бюджета на решение задач интеграции действующих компонентов баз данных.) Именно этим объясняется активный интерес к обсуждению архитектурных принципов и возможностей реализации баз данных различных моделей -- постреляционных, объектно-реляционных, XML.

1.2 Новые области применения баз данных

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

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

базы данных по промышленной, строительной и сельскохозяйственной продукции

базы данных по экономической и конъюнктурной информации (статистическая, кредитно-финансовая, внешнеторговая)

фактографические базы социальных данных, включающие сведения о населении и о социальной среде

базы данных транспортных систем

справочные данные для населения и учреждений (энциклопедии и справочники, расписания самолетов и поездов, адреса и телефоны граждан и организаций)

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

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

фактографические базы данных в области культуры и искусства

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

Экономические задачи, для решения которых необходимо применять программное обеспечение СУБД, весьма обширны и разнообразны. На его основе строятся информационные системы предприятий различных уровней (от малых до крупных). Области применения баз данных традиционно занимает те области деятельности человека, где ему приходится сталкиваться с большим объемом разнообразной информации. Первые базы данных в основном применялись в таких фундаментальных науках как, ядерная физика, химия, космонавтика, и других науках требующих систематического подхода к работе с данными. Дальнейшее развитие компьютерных технологий и компьютеризация общества привела к тому что, базы данных стали разрабатываться практически во всех сферах деятельности человека, и применятся в разных предприятиях от сельского хозяйства до финансово-экономических систем. Последними инновациями применения баз данных стала всемирная паутина Internet, которая по своей сути является огромной базой данных. Соответственно такое распространения баз данных требует и новых программных средств управления ими.

Вот несколько примеров приложений нового поколения, которые определяют потребности в новых средствах разработки баз данных и возможностях применения их. Мы рассмотрим кратко пять таких приложений.

1.База данных Системы наблюдения Земли (EOSDIS)

Система наблюдения Земли (EOS - Earth Observing System) представляет собой множество спутников, которые запускает NASA начиная с 1998. Их назначение - сбор информации, необходимой для исследователей, занятых изучением долгосрочных тенденций состояния атмосферы, океанов, земной поверхности. Спутники будут поставлять информацию в объеме 1/3 Пбайт (Petabyte - 1015 байт) в год. Предполагается, что эти данные будут интегрироваться с уже существующей информацией, а также с данными из других источников (зарубежные спутники, наземные станции наблюдения) и накапливаться в базе данных EOSDIS (EOS Data and Information System) невиданных прежде масштабов.

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

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

Выработка эффективных механизмов просмотра и поиска интересующей информации.

2.Электронная коммерция

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

Как и проект EOSDIS, система электронной коммерции предполагает сетевое взаимодействие огромного числа участников торговых сделок. Разница заключается в том, что в EOSDIS имеется один главный поставщик информации и множество ее потребителей, а торговая система подразумевает наличие множества поставщиков и множества потребителей. Кроме того, участники в данном случае могут испытывать определенное взаимное недоверие и, возможно, имеют свои частные закрытые информационные системы. Наиболее сложные проблемы, связанные с проектами этого рода, следующие.

Система электронной коммерции должна иметь высоконадежные средства распределенной аутентификации и перевода денежных сумм.

3.Информационная система здравоохранения

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

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

Интеграция разнородных источников уже накопленной информации. Средства контроля доступа, обеспечивающие необходимый уровень конфиденциальности. Интерфейсы доступа к информации, удобные для разных категорий работников здравоохранения.

4.Электронные публикации

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

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

Обработка и пересылка очень больших объемов данных с высокой скоростью. Типичный документ содержит объекты данных размером в диапазоне от мегабайт до гигабайт и может требовать доставки в режиме реального времени.

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

5. Коллективное проектирование

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

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

Коллективное проектирование требует новых форм управления совместным доступом к базам данных и механизмов разделения информации.

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

Глава 2. Базы данных

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

Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Сделать это возможно, только если данные структурированы.

Структурирование -- это введение соглашений о способах представления данных.

Неструктурированными называют данные, записанные, например, в текстовом файле.

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

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

База данных (БД) -- это поименованная совокупность структурированных данных, относящихся к определенной предметной области.

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

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

2.1 Классификация баз данных

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.

Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).

По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

* файл-сервер;

* клиент-сервер.

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

Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SOL.

2.2 Структурные элементы базы данных

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

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

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

тип (символьный, числовой, календарный);

длина (например, 15 байт, причем будет определяться максимально возможным количеством символов);

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

Запись -- совокупность логически связанных полей. Экземпляр записи -- отдельная реализация записи, содержащая конкретные значения ее полей.

Файл (таблица) -- совокупность экземпляров записей одной структуры.

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

2.3 Понятие информационного объекта

Информационный объект -- это описание некоторой сущности (реального объекта, явления, процесса, события) в виде совокупности логически связанных реквизитов (информационных элементов). Такими сущностями для информационных объектов могут служить: цех, склад, материал, вуз, студент, сдача экзаменов и т.д.

Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например Студент, Сессия, Стипендия.

Информационный объект имеет множество реализации -- экземпляров, каждый из которых представлен совокупностью конкретных значений реквизитов и идентифицируется значением ключа (простого -- один реквизит или составного -- несколько реквизитов). Остальные реквизиты информационного объекта являются описательными. При этом одни и те же реквизиты в одних информационных объектах могут быть ключевыми, а в других - описательными. Информационный объект может иметь несколько ключей.

2.4 Нормализация отношений

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

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

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

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

Первая нормальная форма.

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

Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) наводится в первой нормальной форме.

Вторая нормальная форма.

Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.

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

Функциональная зависимость реквизитов -- зависимость, при которой экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.

Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.

В случае составного ключа вводится понятие функционально полной зависимости.

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

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

Третья нормальная форма.

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

2.5 Типы связей

Все информационные объекты предметной области связаны между собой. Различаются связи нескольких типов, для которых введены следующие обозначения:

один к одному (1:1);

один ко многим (1 : М);

многие ко многим (М : М).

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид.

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

Глава 3. Модели данных

3.1 Сведенья о моделях данных

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них оказалась модель «сущность-связь».

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

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

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

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

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

3.2 Виды моделей данных

Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.

Модель данных -- совокупность структур данных и операций их обработки.

СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве.

Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.

Иерархическая модель данных

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

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел -- это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.

К каждой записи базы данных существует только один (иерархический) путь от корневой записи.

Сетевая модель данных

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

Реляционная модель данных

Понятие реляционный (англ. relation -- отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

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

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

каждый элемент таблицы -- один элемент данных;

все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

каждый столбец имеет уникальное имя;

одинаковые строки в таблице отсутствуют;

порядок следования строк и столбцов может быть произвольным.

Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы -- атрибутам отношений, доменам, полям.

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

Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ -- ключ второй таблицы.

3.3 Проектирование модели данных

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

В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир в целом) принято рассматривать в виде трех представлений:

представление предметной области в том виде, как она реально существует

как ее воспринимает человек (имеется в виду проектировщик базы данных)

как она может быть описана с помощью символов.

Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (см. Схема 1):

Схема 1 Так называемая модель ANSI/SPARC

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

Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

обследование предметной области, изучение ее информационной структуры

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

моделирование и интеграция всех представлений

По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».

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

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

3.4 Представление данных с помощью модели «сущность-связь»

Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятиях той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity-relationship model, ER-model).

Модель «сущность-связь» основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели «сущность-связь» могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.

Отметим, что модель «сущность-связь» не является моделью данных в строгом смысле, поскольку не определяет операций над данными и ограничивается описанием только их логической структуры.

Модель «сущность-связь» была предложена в 1976 г. Питером Пин-Шэн Ченом.

Элементы модели

Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей. Дадим определения:

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов. Примеры: конкретный человек, предприятие, событие и т.д.

Набор сущностей (entity set) - множество сущностей одного типа(обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида

СОТРУДНИК (ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ).

Например, отделы, на которые подразделяется предприятие, и в которых работают сотрудники, можно описать как ОТДЕЛ (НОМЕР_ОТДЕЛА, НАИМЕНОВАНИЕ).

Множество значений (область определения) атрибута называется доменом. Например, для атрибута ВОЗРАСТ домен (назовем его ЧИСЛО_ЛЕТ) задается интервалом целых чисел больших нуля, поскольку людей с отрицательным возрастом не бывает.

В упомянутой статье П. Чена атрибут определяется как функция, отображающая набор сущностей в набор значений или в декартово произведение наборов значений. Так атрибут ВОЗРАСТ производит отображение в набор значений (домен) ЧИСЛО_ЛЕТ. Атрибут ИМЯ производит отображение в декартово произведение наборов значений ИМЯ, ФАМИЛИЯ и ОТЧЕСТВО.

Отсюда определяется ключ сущности - группа атрибутов, такая, что отображение набора сущностей в соответствующую группу наборов значений является взаимнооднозначным отображением. Другими словами: ключ сущности - это один или более атрибутов, уникально определяющих данную сущность. В нашем примере ключом сущности СОТРУДНИК является атрибут ТАБЕЛЬНЫЙ_НОМЕР (конечно, только в том случае, если все табельные номера на предприятии уникальны).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями. Примеры:

поскольку каждый сотрудник работает в каком-либо отделе, между сущностями СОТРУДНИК и ОТДЕЛ существует связь «работает в» или ОТДЕЛ-РАБОТНИК;

так как один из работников отдела является его руководителем, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь «руководит» или ОТДЕЛ-РУКОВОДИТЕЛЬ;

могут существовать и связи между сущностями одного типа, например связь РОДИТЕЛЬ - ПОТОМОК между двумя сущностями ЧЕЛОВЕК.

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

К сожалению, не существует общих правил определения, что считать сущностью, а что связью. В рассмотренном выше примере мы положили, что «руководит»- это связь. Однако, можно рассматривать сущность «руководитель», которая имеет связи «руководит» с сущностью «отдел» и «является» с сущностью «сотрудник».

Связь также может иметь атрибуты. Например, для связи ОТДЕЛ-РАБОТНИК можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ.

Роль сущности в связи - функция, которую выполняет сущность в данной связи. Например, в связи РОДИТЕЛЬ-ПОТОМОК сущности ЧЕЛОВЕК могут иметь роли «родитель» и «потомок». Указание ролей в модели «сущность-связь» не является обязательным и служит для уточнения семантики связи.

Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.

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

В случае n=2, т.е. когда связь объединяет две сущности, она называется бинарной. Доказано, что n-арный набор связей (n>2) всегда можно заменить множеством бинарных, однако первые лучше отображают семантику предметной области.

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

Один к одному (обозначается 1 : 1 ). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. В рассмотренном нами примере это связь «руководит», поскольку в каждом отделе может быть только один начальник, а сотрудник может руководить только в одном отделе. Данный факт представлен на следующем рисунке 1, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией (см. схему 2).

Схема 2 Связь один к одному

Другой важной характеристикой связи помимо ее степени является класс принадлежности входящих в нее сущностей или кардинальность связи. Так как в каждом отделе обязательно должен быть руководитель, то каждой сущности «ОТДЕЛ» непременно должна соответствовать сущность «СОТРУДНИК». Однако, не каждый сотрудник является руководителем отдела, следовательно в данной связи не каждая сущность «СОТРУДНИК» имеет ассоциированную с ней сущность «ОТДЕЛ».

Таким образом, говорят, что сущность «СОТРУДНИК» имеет обязательный класс принадлежности (этот факт обозначается также указанием интервала числа возможных вхождений сущности в связь, в данном случае это 1,1), а сущность «ОТДЕЛ» имеет необязательный класс принадлежности (0,1).

Теперь данную связь мы можем описать как 0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 будем обозначать следующим образом (см. схему 2):

Схема 3 Бинарные связи первой степени

Один ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе. Графически степень связи n отображается «древообразной» линией, так это сделано на следующей схеме (схема 3).

Схема 4 Отображение связи ОТДЕЛ - СОТРУДНИК

Данный рисунок дополнительно иллюстрирует тот факт, что между двумя сущностями может быть определено несколько наборов связей.

Здесь также необходимо учитывать класс принадлежности сущностей. Каждый сотрудник должен работать в каком-либо отделе, но не каждый отдел (например, вновь сформированный) должен включать хотя бы одного сотрудника. Поэтому сущность «ОТДЕЛ» имеет обязательный, а сущность «СОТРУДНИК» необязательный классы принадлежности. Кардинальность бинарных связей степени n будем обозначать так (схема 4):

Схема 5 Бинарные связи n-ой степени

Много к одному (n : 1 ). Эта связь аналогична отображению 1 : n. Предположим, что рассматриваемое нами предприятие строит свою деятельность на основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели «сущность-связь» с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности КОНТРАКТ (НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК(НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет иметь степень n : 1 (см. схему 5).

Схема 5 Отображение связи КОНТРАКТ - ЗАКАЗЧИК

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

Многие ко многим (n : n). В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пусть на рассматриваемом нами предприятии для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень n : n (см. схему 6).

Схема 6 Отображение связи СОТРУДНИК - РАБОЧАЯ_ГРУППА

Если существование сущности x зависит от существования сущностиy, то x называется зависимой сущностью (иногда сущность x называют «слабой», а «сущность» y - сильной).

В качестве примера рассмотрим связь между ранее описанными сущностями РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая группа создается только после того, как будет подписан контракт с заказчиком, и прекращает свое существование по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным прямоугольником, а ее связь с сильной сущностью линией со стрелкой (см. схему 7).

Схема 7 Отображение связи РАБОЧАЯ_ГРУППА - КОНТРАКТ

Заметим, что кардинальность связи для сильной сущности всегда будет (1,1). Класс принадлежности и степень связи для зависимой сущности могут быть любыми. Предположим, например, что рассматриваемое нами предприятие пользуется несколькими банковскими кредитами, которые представляются набором сущностей: КРЕДИТ(НОМЕР_ДОГОВОРА,СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому кредиту должны осуществляться выплаты процентов и платежи в счет его погашения. Этот факт представляется набором сущностей ПЛАТЕЖ(ДАТА, СУММА) и набором связей «осуществляется по». В том случае, когда получение запланированного кредита отменяется, информация о нем должна быть удалена из базы данных. Соответственно, должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ (см. схему 8).

Схема 8 Отображение связи ПЛАТЕЖ - КРЕДТИТ

Глава 4. Создание базы данных

4.1 Определение модели данных

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

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

Информационные конструкции, операции и ограничения моделей данных выбираются из достаточно небольшого множества вариантов, характеризующего "крупные" информационные объекты и операции. В частности, не допускается рассмотрение отдельных символов данных, операций сложения атрибутов, ограничения на соответствие типов данных и т. п., что характерно для языков программирования.

Информационные объекты послужили основой для объектно-ориентированного проектирования систем, когда фиксируется множество информационных объектов и действий над объектами. Типичный список действий включает в себя создание/уничтожение объекта, редактирование объекта, фиксацию одного объекта в качестве части другого объекта, связывание объектов, синхронизацию действий над объектами.

Довольно-таки часто все названные объекты встраиваются в структуру отношений, которые можно считать простейшими универсальными объектами.

Количество существенно различающихся моделей данных определяется наличием различных множеств информационных конструкций.

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

4.2 Инфологическое моделирование предметной области

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

...