Создание баз данных
Введение 2
1 Понятие баз данных 4
2 Модели представления данных 8
2.1 Иерархическая модель данных 8
2.2 Сетевая модель данных 11
2.3 Реляционная модель данных
2.3.1 Атрибуты
2.3.2 Домены и отношения
2.2.3 Целостность данных
2.3.4 Индексы 12
14
14
16
18
3 Проектирование реляционных баз данных
Нормализация
3.1 Первая нормальная форма
3.2 Вторая нормальная форма
3.3 Четвертая и пятая нормальные формы 20
20
20
21
22
4 Локальные базы данных и архитектура "файл.сервер" 23
5 Постановка задачи 24
6 Реализация программного обеспечения 25
Заключение 28
Список использованной литературы 29
Примечание (листинг программы) 30
1 Понятие баз данных 4
2 Модели представления данных 8
2.1 Иерархическая модель данных 8
2.2 Сетевая модель данных 11
2.3 Реляционная модель данных
2.3.1 Атрибуты
2.3.2 Домены и отношения
2.2.3 Целостность данных
2.3.4 Индексы 12
14
14
16
18
3 Проектирование реляционных баз данных
Нормализация
3.1 Первая нормальная форма
3.2 Вторая нормальная форма
3.3 Четвертая и пятая нормальные формы 20
20
20
21
22
4 Локальные базы данных и архитектура "файл.сервер" 23
5 Постановка задачи 24
6 Реализация программного обеспечения 25
Заключение 28
Список использованной литературы 29
Примечание (листинг программы) 30
Важнейшим фактором успешной деятельности предприятия является умение его руководства чувствовать рынок и ориентироваться на него. Перед любой компанией стоят две основные задачи: уметь заботиться о себе и видеть окружающую действительность. “Заботиться о себе” — значит наводить порядок в технологиях деятельности, процедурах документооборота, организационно-штатной структуре. Одним из механизмов решения задачи наведения порядка является постановка на предприятии методологии управленческого учета, применение которого даст ответы на вопросы: “что”, “где”, “когда”, “как”, “почему”, “сколько”, “в чем причина” и т.д. Наведение порядка на предприятии приведет к повышению внутренней эффективности предприятия. Однако успешная внутренняя жизнь предприятия — это необходимое, но не достаточное условие выживания, а тем более для занятия ведущих позиций на рынке. Чтобы повысить внешнюю эф-фективность, следует адаптироваться к требованиям окружающего мира, потребностям рынка, научиться управлять поставщиками и заказчиками. Возможность правильно и своевременно реагировать на внешнюю среду позволяет стратегически мыслить.
В последнее время отчетливо проявляется тенденция перехода от детального управления внутренней деятельностью к управлению заказчиками и поставщиками. Конкурентоспособность компании все больше зависит от способности создавать и углублять взаимоотношения с другими компаниями (партнерами, конкурентами, заказчиками или поставщиками). Причинами этого являются:
• расширение экономического пространства, на котором функционируют предприятия;
• появление нового стратегического ресурса — информации;
• необходимость учитывать фактор времени.
Для решения вышеперечисленных задач необходимо иметь эффективную систему управления предприятием, включающую систему менеджмента качества, и информационную систему ее поддержки.
Два подхода к проектированию.
В последнее время отчетливо проявляется тенденция перехода от детального управления внутренней деятельностью к управлению заказчиками и поставщиками. Конкурентоспособность компании все больше зависит от способности создавать и углублять взаимоотношения с другими компаниями (партнерами, конкурентами, заказчиками или поставщиками). Причинами этого являются:
• расширение экономического пространства, на котором функционируют предприятия;
• появление нового стратегического ресурса — информации;
• необходимость учитывать фактор времени.
Для решения вышеперечисленных задач необходимо иметь эффективную систему управления предприятием, включающую систему менеджмента качества, и информационную систему ее поддержки.
Два подхода к проектированию.
1. Архангельский В.К. «Базы данных», Москва, 2003 г.;
2. Петр Дарахвелидзе, Евгений Марков «Программирование в Delphi 7», Санкт-Петербург, 2003.;
3. Конноли Т. «Базы данных», М., 2001 г.;
4. Попов Р.К. «Базы данных», С.-П., 2002 г.
5. Фаронов В.В. «Программирование в Delphi 6», М., 2003 г.;
6. Петров А.П. «Информационные системы», М., 2002 г.;
7. Архангельский А.Я. «Приемы программирования в Delphi», С.-П., 2003 г.;
2. Петр Дарахвелидзе, Евгений Марков «Программирование в Delphi 7», Санкт-Петербург, 2003.;
3. Конноли Т. «Базы данных», М., 2001 г.;
4. Попов Р.К. «Базы данных», С.-П., 2002 г.
5. Фаронов В.В. «Программирование в Delphi 6», М., 2003 г.;
6. Петров А.П. «Информационные системы», М., 2002 г.;
7. Архангельский А.Я. «Приемы программирования в Delphi», С.-П., 2003 г.;
Дисциплина: Информатика, Программирование, Базы данных
Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 31 страниц
В избранное:
Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 31 страниц
В избранное:
СОДЕРЖАНИЕ
Введение 2
1 Понятие баз данных 4
2 Модели представления данных 8
2.1 Иерархическая модель данных 8
2.2 Сетевая модель данных 11
2.3 Реляционная модель данных 12
2.3.1 Атрибуты 14
2.3.2 Домены и отношения 14
2.2.3 Целостность данных 16
2.3.4 Индексы 18
3 Проектирование реляционных баз данных 20
Нормализация 20
3.1 Первая нормальная форма 20
3.2 Вторая нормальная форма 21
3.3 Четвертая и пятая нормальные формы 22
4 Локальные базы данных и архитектура "файл-сервер" 23
5 Постановка задачи 24
6 Реализация программного обеспечения 25
Заключение 28
Список использованной литературы 29
Примечание (листинг программы) 30
ВВЕДЕНИЕ
Важнейшим фактором успешной деятельности предприятия является умение
его руководства чувствовать рынок и ориентироваться на него. Перед любой
компанией стоят две основные задачи: уметь заботиться о себе и видеть
окружающую действительность. “Заботиться о себе” — значит наводить порядок
в технологиях деятельности, процедурах документооборота, организационно-
штатной структуре. Одним из механизмов решения задачи наведения порядка
является постановка на предприятии методологии управленческого учета,
применение которого даст ответы на вопросы: “что”, “где”, “когда”, “как”,
“почему”, “сколько”, “в чем причина” и т.д. Наведение порядка на
предприятии приведет к повышению внутренней эффективности предприятия.
Однако успешная внутренняя жизнь предприятия — это необходимое, но не
достаточное условие выживания, а тем более для занятия ведущих позиций на
рынке. Чтобы повысить внешнюю эффективность, следует адаптироваться к
требованиям окружающего мира, потребностям рынка, научиться управлять
поставщиками и заказчиками. Возможность правильно и своевременно
реагировать на внешнюю среду позволяет стратегически мыслить.
В последнее время отчетливо проявляется тенденция перехода от
детального управления внутренней деятельностью к управлению заказчиками и
поставщиками. Конкурентоспособность компании все больше зависит от
способности создавать и углублять взаимоотношения с другими компаниями
(партнерами, конкурентами, заказчиками или поставщиками). Причинами этого
являются:
• расширение экономического пространства, на котором функционируют
предприятия;
• появление нового стратегического ресурса — информации;
• необходимость учитывать фактор времени.
Для решения вышеперечисленных задач необходимо иметь эффективную
систему управления предприятием, включающую систему менеджмента качества, и
информационную систему ее поддержки.
Два подхода к проектированию.
Можно выделить два основных подхода к проектированию систем
управления предприятием и информационных систем их поддержки:
структурный и процессный.
Первый подход основан на использовании организационной структуры
компании, когда проектирование системы идет по структурным подразделениям.
Технологии деятельности в этом случае описываются через технологии работы
структурных подразделений, а взаимодействие структурных подразделений —
через модель верхнего уровня. Если компания представляет собой сложную
структуру типа холдинга, или предприятие-сеть, то необходимо также иметь
модель взаимодействия всех входящих в него элементов, в которой будут
отражены не только технологические, но также финансовые и юридические
моменты.
Главным недостатком структурного подхода является привязка к
организационной структуре, которая очень быстро меняется, поэтому в
Системный проект информационной системы приходится часто вносить изменения.
О важности и структуре Системного проекта авторы уже писали в статье
“Реорганизация АСУ промышленных предприятий” (КомпьютерПресс № 7’97) и в
статье “Методологический подход проектирования корпоративной информационной
системы предприятия” (материалы конференции “Корпоративные системы’96”,
компания “СофтСервис”). Хорошо, если на предприятии есть обученные
специалисты, способные быстро и качественно актуализировать этот документ.
Но это только начало! Ведь актуализировать надо также и саму информационную
систему! Как правило, это достаточно трудоемкий, длительный и утомительный
процесс.
Несколько по-иному обстоит дело при процессном подходе. Этот подход
ориентирован не на организационную структуру, а на бизнес-процессы. С точки
зрения авторов, он наиболее перспективен. Бизнес-процессы, в отличие от
организационной структуры, меняются реже. Как правило, основных бизнес-
процессов на предприятии немного, обычно не более десяти.
Процессный подход подводит к необходимости перехода на так
называемое тощее производство или тощую ресурсосберегающую организационную
структуру (Lean production). Основными чертами такой реорганизации
являются:
• широкое делегирование полномочий и ответственности исполнителям;
• сокращение количества уровней принятия решения;
• сочетание принципа целевого управления с групповой организацией
труда;
• повышенное внимание к вопросам обеспечения качества продукции или
услуг, а также работы предприятия в целом;
• автоматизация технологий выполнения бизнес-процессов.
1. ПОНЯТИЕ БАЗЫ ДАННЫХ
Существует хорошо известное, но трудно реализуемое на практике
понятие базы данных как большого по объему хранилища, в которое организация
помещает все необходимые ей данные и из которого различные пользователи
могут эти данные получать. Устройства памяти, в которых хранятся все
данные, могут быть расположены в одном или нескольких местах; в последнем
случае они должны быть связаны средствами передачи данных. К данным должны
иметь доступ программы.
Действительно, большинство существующих на сегодняшний день баз
данных предназначено для ограниченного ряда приложений. Часто на одной ЭВМ
создается несколько баз данных. Со временем базы данных, предназначенные
для реализации отдельных родственных функций, можно будет объединить, если
такое объединение будет способствовать увеличению эффективности и
интенсивности использования всей системы.
Базу данных можно определить как совокупность взаимосвязанных
хранящихся вместе данных при наличии такой минимальной избыточности,
которая допускает их использование оптимальным образом для одного или
нескольких приложений; данные запоминаются так, чтобы они были независимы
от программ, использующих эти данные; для добавления новых или модификации
существующих данных, а также для поиска данных в базе данных применяется
общий управляемый способ.
Говорят, что система содержит совокупность баз данных, если эти базы
данных структурно полностью самостоятельны. В системах с простой
организацией данных для каждого приложения создается своя совокупность
записей. Назначение базы данных заключается в том, чтобы одну и ту же
совокупность данных можно было использовать для максимально возможного
числа приложений. Исходя из этого, базу данных часто разрабатывают в
качестве хранилища такой информации, необходимость в котором возникает в
процессе выполнения определенных функций на заводе, правительственном
учреждении или какой-либо другой организации. Такая база данных должна
обеспечивать возможность не только получения информации, но также
постоянной ее модификации, необходимой для процессов управления в данной
организации, может оказаться, что для получения информации для целей
планирования или ответов на вопросы потребуется осуществлять поиск в базе
данных. Совокупностью данных могут пользоваться не
сколько ведомств независимо от того, имеются ли при этом между ними
ведомственные барьеры.
База данных может разрабатываться для пакетной обработки данных,
обработки в реальном времени или оперативной обработки (в этом случае
обработка каждого запроса завершается к определенному моменту времени, но
при этом на время обработки не накладывается жестких ограничений,
существующих в системах реального времени). Во многих базах данных
предусмотрена совокупность этих методов обработки, а во многих системах с
базами данных обслуживание терминалов в реальном времени происходит
одновременно с пакетной обработкой данных.
Большая часть дисковых или ленточных библиотек, которые существовали
до использования средств управления базами данных, содержали большое
количество повторяющейся информации. При запоминании многих элементов
данных допускалась избыточность, так как на носители информации для
различных целей записывались одни и те же данные и, кроме того, хранились
различные варианты модификаций одних и тех же данных. База данных
предоставляет возможность в значительной степени избавиться от такой
избыточности. Базу данных иногда определяют как неизбыточную совокупность
элементов данных. Однако в действительности для уменьшения времени доступа
к данным или упрощения способов адресации во многих базах данных
избыточность в незначительной степени присутствует. Некоторые записи
повторяются для того, чтобы обеспечить возможность восстановления данных
при их случайной потере. Чтобы база данных была неизбыточной и
удовлетворяла другим требованиям, приходится идти на компромисс. В этом
случае говорят об управляемой, или минимальной, избыточности или о том, что
хорошо разработанная база данных свободна от излишней избыточности.
Неуправляемая избыточность имеет несколько недостатков. Во-первых,
хранение нескольких копий данных приводит к дополнительным затратам. Во-
вторых, при обновлении, по крайней мере, нескольких избыточных копий
необходимо выполнять многократные операции обновления. Избыточность поэтому
обходится значительно дороже в тех случаях, когда при обработке файлов
обновляется большое количество информации или, что еще хуже, часто вводятся
новые элементы или уничтожаются старые. В-третьих, вследствие того, что
различные копии данных могут соответствовать различным стадиям обновления,
информация, выдаваемая системой, может быть противоречивой.
Если не использовать базы данных, то при обработке большого
количества информации появится так много избыточных данных, что фактически
станет невозможным сохранять их все на одном и том же уровне обновления.
Очень часто пользователи обнаруживают явные противоречия в данных и поэтому
испытывают недоверие к полученной от ЭВМ информации. Невозможность хранения
избыточных данных на одинаковом уровне обновления является основным
препятствием в обработке данных с помощью ЭВМ. Одной из наиболее важных
характеристик большинства баз данных является их постоянное изменение и
расширение. По мере добавления новых типов данных или при появлении новых
приложений должна быть обеспечена возможность быстрого изменения структуры
базы данных. Реорганизация базы данных должна осуществляться по возможности
без перезаписи прикладных программ и в целом вызывать минимальное
количество преобразований. Простота изменения базы данных может оказать
большое влияние на развитие приложений баз данных в управлении
производством.
О независимости данных часто говорят как об одном из основных
свойств базы данных. Под этим подразумевается независимость данных и
использующих их прикладных программ друг от друга в том смысле, что
изменение одних не приводит к изменению других. В частности, прикладной
программист изолирован от влияния изменений данных и их организации, а
также от изменения характеристик физических устройств, на которых они
хранятся. В действительности же полностью независимыми данные бывают так же
редко, как и полностью неизбыточными. Как мы увидим ниже, независимость
данных определяется с различных точек зрения. Сведения, которыми должен
располагать программист для доступа к данным, различны для различных баз
данных. Тем не менее, независимость данных—это одна из основных причин
использования систем управления базами данных. В том случае, когда один
набор элементов данных используется для многих приложений, между элементами
этого набора устанавливается множество различных взаимосвязей, необходимых
для соответствующих прикладных программ. Организация базы данных в
значительной степени зависит от реализации взаимосвязей между элементами
данных и записями, а также от того, как и где эти данные хранятся. В базе
данных, используемой многими приложениями, должны быть установлены
многочисленные промежуточные взаимосвязи между элементами. В этом случае
при хранении и использовании данных контролировать их правильность,
обеспечивать их защиту и секретность труднее, чем при хранении данных в
простых, несвязанных файлах. Что касается обеспечения секретности данных и
восстановления их после сбоев, то этот вопрос является очень важным при
конструировании баз данных.
В некоторых системах средства управления базами данных применяются
для того, чтобы пользователи могли использовать данные таким путем, который
не был предусмотрен разработчиками системы. Администраторы или сотрудники
могут обращаться к вычислительной системе с вопросами, которые заранее в
ней не предусматривались. Наличие этой возможности означает такую
организацию данных в системе, при которой доступ к ним можно осуществлять
по различным путям, причем одни и те же данные могут использоваться для
ответов на различные вопросы. Вся существенная информация об объектах
запоминается одновременно и полностью, а не только та ее часть, которая
необходима для одного приложения. В настоящее время существуют СУБД,
реализующие эти возможности как на уровне локальных баз данных,
расположенных на одном диске (Paradox, Dbase), так и промышленных баз
данных (Acsess, Oracle, FoxPro).
Термины база данных (БД) и система управления базами данных (СУБД)
чаще всего употребляются как относящиеся к компьютерам. Понятие БД можно
применить к любой связанной между собой по определенному признаку
информации, хранимой и организованной особым образом - как правило, в виде
таблиц По сути. БД - это некоторое подобие электронной картотеки,
электронного хранилища данных, которое хранится в компьютере в виде одного
или нескольких файлов. При этом возникает необходимость в выполнении ряда
операций с БД. в первую очередь это:
* добавление новой информации в существующие файлы БД:
* добавление новых пустых файлов в БД:
* изменение (модификация) информации в существующих
файлах БД:
* поиск информации в БД:
* удаление информации из существующих файлов БД:
• удаление файлов из БД.
Компьютеризированная информационная система представляет собой
программный комплекс, задачи которого состоят в поддержке надежного
хранения БД в компьютере, выполнении преобразований информации и
соответствующих вычислений, предоставлении пользователям удобного и легко
осваиваемого интерфейса. Традиционно объемы информации, с которыми
приходится иметь дело таким системам, довольно велики, а сами БД имеют
достаточно сложную структуру. Примерами информационных систем являются
системы заказа железнодорожных или авиационных билетов, банковские системы
и многие другие.
2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ
С ростом популярности СУБД в 70-80-х годах появилось множество
различных моделей данных. У каждой из них имелись свои достоинства и
недостатки, которые сыграли ключевую роль в развитии реляционной модели
данных, появившейся во многом благодаря стремлению упростить и упорядочить
первые модели данных.
Современные БД основываются на использовании моделей данных (МД),
позволяющих описывать объекты предметных областей и взаимосвязи между
ними существуют три основные МД и их комбинации, на которых основываются
БД: реляционная модель данных (РМД), сетевая модель данных (СМД),
иерархическая модель данных (ИМД).
Основное различие между этими моделями данных состоит в способах
описания взаимодействий между объектами и атрибутами. Взаимосвязь
выражает отношение между множествами данных.
Используют взаимосвязи "один к одному", "один ко многим" и
"многие ко многим". "Один к одному" - это взаимно однозначное
соответствие, которое устанавливается между одним объектом и одним
атрибутом. "Один ко многим" - это соответствие между одним объектом и
многими атрибутами. "Многие ко многим" - это соответствие между многими
объектами и многими атрибутами.
2.1 Иерархическая модель данных
Иерархическая модель данных основана на понятии деревьев,
состоящих из вершин и ребер. Вершине дерева ставится в соответствие
совокупности атрибутов данных, характеризующих некоторый объект. Вершины
и ребра дерева как бы образуют иерархическую древовидную структуру,
состоящую из n уровней.
Первую вершину называют корневой вершиной. Он удовлетворяет
условиям:
1. Иерархия начинается с корневой вершины.
2. Каждая вершина соответствует одному или нескольким атрибутам.
3. Hа уровнях с большим номером находятся зависимые вершины. Вершин
предшествующего уровня является начальной для новых зависимых вершин.
4. Каждая вершина, находящаяся на уровне i, соединена с одной и только
одной вершиной уровня i-1, за исключением корневой вершины.
5. Корневая вершина может быть связана с одной или несколькими
зависимыми вершинами.
6. Доступ к каждой вершине происходит через корневую по единственному
пути
7. Существует произвольное количество вершин каждого уровня.
Иерархическая модель данных состоит из нескольких деревьев, т.е.
является лесом. Каждая корневая вершин образует начало записи логической
базы данных. В ИМД вершины, находящиеся на уровне i, называют
порожденными вершин ми н уровне i-1.
Операции в ИМД имеют нелогичный позаписный характер. Аппарат
перемещения по структуре в графовых моделях служит для установки тех
объектов данных, к которым будет применяться очередная операция
манипулирования данными. Такие объекты называются текущими. Механизмы
доступа к данным и перемещения по структуре данных в таких моделях
достаточно сложны и существенным образом опираются на концепцию текущего
состояния механизма доступа.
Основные достоинства ИМД: простота построения и
использования, обеспечение определенного уровня независимости данных,
простота оценки операционных характеристик. Основные недостатки:
отношение "многие ко многим" реализуется очень сложно, дает громоздкую
структуру и требует хранения избыточных данных, что особенно нежелательно
на физическом уровне, иерархическая упорядоченность усложняет операции
удаления и включения, доступ к любой вершине возможен только через
корневую, что увеличивает время доступа.
К числу СУБД иерархического типа можно отнести PCFocus,
Team-Up, Data Edge, также разработанную в нашей стране систему HИКА,
преемницу широко распространенной советской системы ИHЕС для ЕС ЭВМ.
Одной из наиболее важных сфер применения первых иерархических СУБД
было планирование производства для компаний, занимающихся выпуском
продукции. Например, если автомобильная компания хотела выпустить 10000
машин одной модели и 5000 машин другой модели, ей необходимо было знать,
сколько деталей следует заказать у своих поставщиков. Чтобы ответить на
этот вопрос, необходимо определить, из каких деталей состоят эти части и
т.д. Например, машина состоит из двигателя, корпуса и ходовой части;
двигатель состоит из клапанов, цилиндров, свеч и т.д. Работа со списками
составных частей была как будто специально предназначена для компьютеров.
Список составных частей изделия по своей природе является
иерархической структурой. Для хранения данных, имеющих такую структуру,
была разработана иерархическая модель данных, которую иллюстрирует рис.
2.1.
В этой модели каждая запись базы данных представляла конкретную
деталь. Между записями существовали отношения предокпотомок, связывающие
каждую часть с деталями, входящими в неё.
Чтобы получить доступ к данным, содержащимся в базе данных,
программа могла:
• найти конкретную деталь (правую дверь) по её номеру;
• перейти "вниз" к первому потомку (ручка двери);
• перейти "вверх" к предку (корпус);
• перейти "в сторону" к другому потомку (правая дверь).
Таким образом, для чтения данных из иерархической базы данных
требовалось перемещаться по записям, за один раз переходя на одну запись
вверх, вниз или в сторону.
Ограничения целостности.
Автоматически поддерживается целостность ссылок между предками и
потомками. Основное правило: никакой потомок не может существовать без
своего родителя. Заметим, что аналогичное поддержание целостности по
ссылкам между записями, не входящими в одну иерархию, не поддерживается.
В иерархических системах поддерживалась некоторая форма
представлений БД на основе ограничения иерархии.
2.2 Сетевая модель данных
Сетевая модель данных замышлялась как инструмент для
пользователей баз данных - программистов. В связи с этим в СМД больше
внимания уделяется структуризации данных, чем развитию ее операционных
возможностей.
В СМД элементарные данные и отношения между ними
представляются в виде ориентированной сети (вершины - данные, дуги -
отношения).
Если структура данных оказывалась сложнее, чем обычная иерархия,
простота структуры иерархической базы данных становилась её недостатком.
Например, в базе данных для хранения заказов один заказ мог участвовать в
трёх различных отношениях предокпотомок, связывающих заказ с клиентом,
разместившим его, со служащим, принявшим его, и с заказанным товаром, что
иллюстрирует рис. 2.2. Такие структуры данных не соответствовали строгой
иерархии IMS.
В связи с этим для таких приложений, как обработка заказов, была
разработана новая сетевая модель данных. Она являлась улучшенной
иерархической моделью, в которой одна запись могла участвовать в нескольких
отношениях предокпотомок. В сетевой модели такие отношения назывались
множествами. В 1971 году на конференции по языкам систем данных был
опубликован официальный стандарт сетевых баз данных, который известен как
модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую
СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах
независимые производители программного обеспечения реализовали сетевую
модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom
и СУБД Adabas, которые приобрели большую популярность.
Сетевые базы данных обладали рядом преимуществ:
• Гибкость. Множественные отношения предокпотомок позволяли сетевой базе
данных хранить данные, структура которых была сложнее простой иерархии.
• Стандартизация. Появление стандарта CODASYL популярность сетевой модели,
а такие поставщики мини-компьютеров, как Digital Equipment Corporation и
Data General, реализовали сетевые СУБД.
• Быстродействие. Вопреки своей большой сложности, сетевые базы данных
достигали быстродействия, сравнимого с быстродействием иерархических баз
данных. Множества были представлены указателями на физические записи
данных, и в некоторых системах администратор мог задать кластеризацию
данных на основе множества отношений.
Конечно, у сетевых баз данных были недостатки. Как и иерархические
базы данных, сетевые базе данных были очень жесткими. Наборы отношений и
структуру записей приходилось задавать наперёд. Изменение структуры базы
данных обычно означало перестройку всей базы данных.
Как иерархическая, так и сетевая база данных были инструментами
программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее
часто заказывает компания Acme Manufacturing?", программисту приходилось
писать программу для навигации по базе данных. Реализация пользовательских
запросов часто затягивалась на недели и месяцы, и к моменту появления
программы информация, которую она предоставляла, часто оказывалась
бесполезной.
Ограничения целостности.
В принципе их поддержание не требуется, но иногда требуют
целостности по ссылкам (как в иерархической модели).
2.3 Реляционная модель данных
Недостатки иерархической и сетевой моделей привели к появлению
новой, реляционной модели данных, созданной Коддом в 1970 году и вызвавшей
всеобщий интерес. Реляционная модель была попыткой упростить структуру базы
данных. В ней отсутствовали явные указатели на предков и потомков, а все
данные были представлены в виде простых таблиц, разбитых на строки и
столбцы. На рис. 2.3. показана реляционная версия сетевой базы данных,
содержащей информацию о заказах и приведенной на рис. 2.2.
К сожалению, практическое определение понятия "реляционная база
данных" оказалось гораздо более расплывчатым, чем точное математическое
определение, данное этому термину Коддом в 1970 году. В первых реляционных
СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот
пробел был восполнен только впоследствии. По мере роста популярности
реляционной концепции реляционными стали называться многие базы данных,
которые на деле таковыми не являлись.
В ответ на неправильное использование термина "реляционный" Кодд в
1985 году написал статью, где сформулировал 12 правил, которым должна
удовлетворять любая база данных, претендующая на звание реляционной. С тех
пор двенадцать правил Кодда считаются определением реляционной СУБД. Однако
можно сформулировать и более простое определение:
Реляционной называется база данных, в которой все данные, доступные
пользователю, организованны в виде таблиц, а все операции над данными
сводятся к операциям над этими таблицами.
Приведенное определение не оставляет места встроенным указателям,
имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД
также способна реализовать отношения предокпотомок, однако эти отношения
представлены исключительно значениями данных, содержащихся в таблицах.
Таблица рассматривается как непосредственное хранилище данных.
Традиционно в реляционных системах таблицу называют отношением. Строку
таблицы называют кортежем, а столбец - атрибутом. При этом атрибуты имеют
уникальные (в пределах отношения) имена. Количество кортежей в таблице
называют кардинальным числом, а количество
атрибутов - степенью. Для отношения предусматривают уникальный
идентификатор, то есть один или несколько атрибутов, значения которых в
одно и то же время не бывают одинаковыми - идентификатор называют первичным
ключом. Домен - это множество допустимых однородных значений для того или
иного атрибута. Таким образом, домен можно рассмотреть как именованное
множество данных, причем составные части этого множества являются логически
неделимыми единицами (в качестве домена могут выступать, например, перечень
фамилий сотрудников учреждения, однако не все фамилии могут присутствовать
в таблице).
Отношение содержит две части - заголовок и собственно содержательную
часть. Заголовок содержит конечное множество атрибутов, а содержательная
часть (тело отношения) – множество пар имени атрибута и его значения.
Например, KOD, NAME и SUMM, содержащиеся в заголовке, являются атрибутами,
а скажем, пары SUMM - 25.50 или KOD - 5216 являются элементами тела
отношения.
2.3.1 Атрибуты
Первичный ключ
В реляционных БД, в отличие от других моделей, пользователь
указывает, какие данные для него необходимы, а не то, как это делать. По
этой причине процесс перемещения и навигации по БД в реляционных системах
является автоматическим, а эту задачу в таких СУБД выполняет так называемый
оптимизатор. Его работа заключается, например, в том, чтобы наиболее
эффективным способом произвести выборку данных из БД по запросу Таким
образом, оптимизатор, по крайней мере, должен суметь определить, из каких
таблиц выбираются данные, насколько много информации в этих таблицах, каков
физический порядок записей в таблицах ... продолжение
Введение 2
1 Понятие баз данных 4
2 Модели представления данных 8
2.1 Иерархическая модель данных 8
2.2 Сетевая модель данных 11
2.3 Реляционная модель данных 12
2.3.1 Атрибуты 14
2.3.2 Домены и отношения 14
2.2.3 Целостность данных 16
2.3.4 Индексы 18
3 Проектирование реляционных баз данных 20
Нормализация 20
3.1 Первая нормальная форма 20
3.2 Вторая нормальная форма 21
3.3 Четвертая и пятая нормальные формы 22
4 Локальные базы данных и архитектура "файл-сервер" 23
5 Постановка задачи 24
6 Реализация программного обеспечения 25
Заключение 28
Список использованной литературы 29
Примечание (листинг программы) 30
ВВЕДЕНИЕ
Важнейшим фактором успешной деятельности предприятия является умение
его руководства чувствовать рынок и ориентироваться на него. Перед любой
компанией стоят две основные задачи: уметь заботиться о себе и видеть
окружающую действительность. “Заботиться о себе” — значит наводить порядок
в технологиях деятельности, процедурах документооборота, организационно-
штатной структуре. Одним из механизмов решения задачи наведения порядка
является постановка на предприятии методологии управленческого учета,
применение которого даст ответы на вопросы: “что”, “где”, “когда”, “как”,
“почему”, “сколько”, “в чем причина” и т.д. Наведение порядка на
предприятии приведет к повышению внутренней эффективности предприятия.
Однако успешная внутренняя жизнь предприятия — это необходимое, но не
достаточное условие выживания, а тем более для занятия ведущих позиций на
рынке. Чтобы повысить внешнюю эффективность, следует адаптироваться к
требованиям окружающего мира, потребностям рынка, научиться управлять
поставщиками и заказчиками. Возможность правильно и своевременно
реагировать на внешнюю среду позволяет стратегически мыслить.
В последнее время отчетливо проявляется тенденция перехода от
детального управления внутренней деятельностью к управлению заказчиками и
поставщиками. Конкурентоспособность компании все больше зависит от
способности создавать и углублять взаимоотношения с другими компаниями
(партнерами, конкурентами, заказчиками или поставщиками). Причинами этого
являются:
• расширение экономического пространства, на котором функционируют
предприятия;
• появление нового стратегического ресурса — информации;
• необходимость учитывать фактор времени.
Для решения вышеперечисленных задач необходимо иметь эффективную
систему управления предприятием, включающую систему менеджмента качества, и
информационную систему ее поддержки.
Два подхода к проектированию.
Можно выделить два основных подхода к проектированию систем
управления предприятием и информационных систем их поддержки:
структурный и процессный.
Первый подход основан на использовании организационной структуры
компании, когда проектирование системы идет по структурным подразделениям.
Технологии деятельности в этом случае описываются через технологии работы
структурных подразделений, а взаимодействие структурных подразделений —
через модель верхнего уровня. Если компания представляет собой сложную
структуру типа холдинга, или предприятие-сеть, то необходимо также иметь
модель взаимодействия всех входящих в него элементов, в которой будут
отражены не только технологические, но также финансовые и юридические
моменты.
Главным недостатком структурного подхода является привязка к
организационной структуре, которая очень быстро меняется, поэтому в
Системный проект информационной системы приходится часто вносить изменения.
О важности и структуре Системного проекта авторы уже писали в статье
“Реорганизация АСУ промышленных предприятий” (КомпьютерПресс № 7’97) и в
статье “Методологический подход проектирования корпоративной информационной
системы предприятия” (материалы конференции “Корпоративные системы’96”,
компания “СофтСервис”). Хорошо, если на предприятии есть обученные
специалисты, способные быстро и качественно актуализировать этот документ.
Но это только начало! Ведь актуализировать надо также и саму информационную
систему! Как правило, это достаточно трудоемкий, длительный и утомительный
процесс.
Несколько по-иному обстоит дело при процессном подходе. Этот подход
ориентирован не на организационную структуру, а на бизнес-процессы. С точки
зрения авторов, он наиболее перспективен. Бизнес-процессы, в отличие от
организационной структуры, меняются реже. Как правило, основных бизнес-
процессов на предприятии немного, обычно не более десяти.
Процессный подход подводит к необходимости перехода на так
называемое тощее производство или тощую ресурсосберегающую организационную
структуру (Lean production). Основными чертами такой реорганизации
являются:
• широкое делегирование полномочий и ответственности исполнителям;
• сокращение количества уровней принятия решения;
• сочетание принципа целевого управления с групповой организацией
труда;
• повышенное внимание к вопросам обеспечения качества продукции или
услуг, а также работы предприятия в целом;
• автоматизация технологий выполнения бизнес-процессов.
1. ПОНЯТИЕ БАЗЫ ДАННЫХ
Существует хорошо известное, но трудно реализуемое на практике
понятие базы данных как большого по объему хранилища, в которое организация
помещает все необходимые ей данные и из которого различные пользователи
могут эти данные получать. Устройства памяти, в которых хранятся все
данные, могут быть расположены в одном или нескольких местах; в последнем
случае они должны быть связаны средствами передачи данных. К данным должны
иметь доступ программы.
Действительно, большинство существующих на сегодняшний день баз
данных предназначено для ограниченного ряда приложений. Часто на одной ЭВМ
создается несколько баз данных. Со временем базы данных, предназначенные
для реализации отдельных родственных функций, можно будет объединить, если
такое объединение будет способствовать увеличению эффективности и
интенсивности использования всей системы.
Базу данных можно определить как совокупность взаимосвязанных
хранящихся вместе данных при наличии такой минимальной избыточности,
которая допускает их использование оптимальным образом для одного или
нескольких приложений; данные запоминаются так, чтобы они были независимы
от программ, использующих эти данные; для добавления новых или модификации
существующих данных, а также для поиска данных в базе данных применяется
общий управляемый способ.
Говорят, что система содержит совокупность баз данных, если эти базы
данных структурно полностью самостоятельны. В системах с простой
организацией данных для каждого приложения создается своя совокупность
записей. Назначение базы данных заключается в том, чтобы одну и ту же
совокупность данных можно было использовать для максимально возможного
числа приложений. Исходя из этого, базу данных часто разрабатывают в
качестве хранилища такой информации, необходимость в котором возникает в
процессе выполнения определенных функций на заводе, правительственном
учреждении или какой-либо другой организации. Такая база данных должна
обеспечивать возможность не только получения информации, но также
постоянной ее модификации, необходимой для процессов управления в данной
организации, может оказаться, что для получения информации для целей
планирования или ответов на вопросы потребуется осуществлять поиск в базе
данных. Совокупностью данных могут пользоваться не
сколько ведомств независимо от того, имеются ли при этом между ними
ведомственные барьеры.
База данных может разрабатываться для пакетной обработки данных,
обработки в реальном времени или оперативной обработки (в этом случае
обработка каждого запроса завершается к определенному моменту времени, но
при этом на время обработки не накладывается жестких ограничений,
существующих в системах реального времени). Во многих базах данных
предусмотрена совокупность этих методов обработки, а во многих системах с
базами данных обслуживание терминалов в реальном времени происходит
одновременно с пакетной обработкой данных.
Большая часть дисковых или ленточных библиотек, которые существовали
до использования средств управления базами данных, содержали большое
количество повторяющейся информации. При запоминании многих элементов
данных допускалась избыточность, так как на носители информации для
различных целей записывались одни и те же данные и, кроме того, хранились
различные варианты модификаций одних и тех же данных. База данных
предоставляет возможность в значительной степени избавиться от такой
избыточности. Базу данных иногда определяют как неизбыточную совокупность
элементов данных. Однако в действительности для уменьшения времени доступа
к данным или упрощения способов адресации во многих базах данных
избыточность в незначительной степени присутствует. Некоторые записи
повторяются для того, чтобы обеспечить возможность восстановления данных
при их случайной потере. Чтобы база данных была неизбыточной и
удовлетворяла другим требованиям, приходится идти на компромисс. В этом
случае говорят об управляемой, или минимальной, избыточности или о том, что
хорошо разработанная база данных свободна от излишней избыточности.
Неуправляемая избыточность имеет несколько недостатков. Во-первых,
хранение нескольких копий данных приводит к дополнительным затратам. Во-
вторых, при обновлении, по крайней мере, нескольких избыточных копий
необходимо выполнять многократные операции обновления. Избыточность поэтому
обходится значительно дороже в тех случаях, когда при обработке файлов
обновляется большое количество информации или, что еще хуже, часто вводятся
новые элементы или уничтожаются старые. В-третьих, вследствие того, что
различные копии данных могут соответствовать различным стадиям обновления,
информация, выдаваемая системой, может быть противоречивой.
Если не использовать базы данных, то при обработке большого
количества информации появится так много избыточных данных, что фактически
станет невозможным сохранять их все на одном и том же уровне обновления.
Очень часто пользователи обнаруживают явные противоречия в данных и поэтому
испытывают недоверие к полученной от ЭВМ информации. Невозможность хранения
избыточных данных на одинаковом уровне обновления является основным
препятствием в обработке данных с помощью ЭВМ. Одной из наиболее важных
характеристик большинства баз данных является их постоянное изменение и
расширение. По мере добавления новых типов данных или при появлении новых
приложений должна быть обеспечена возможность быстрого изменения структуры
базы данных. Реорганизация базы данных должна осуществляться по возможности
без перезаписи прикладных программ и в целом вызывать минимальное
количество преобразований. Простота изменения базы данных может оказать
большое влияние на развитие приложений баз данных в управлении
производством.
О независимости данных часто говорят как об одном из основных
свойств базы данных. Под этим подразумевается независимость данных и
использующих их прикладных программ друг от друга в том смысле, что
изменение одних не приводит к изменению других. В частности, прикладной
программист изолирован от влияния изменений данных и их организации, а
также от изменения характеристик физических устройств, на которых они
хранятся. В действительности же полностью независимыми данные бывают так же
редко, как и полностью неизбыточными. Как мы увидим ниже, независимость
данных определяется с различных точек зрения. Сведения, которыми должен
располагать программист для доступа к данным, различны для различных баз
данных. Тем не менее, независимость данных—это одна из основных причин
использования систем управления базами данных. В том случае, когда один
набор элементов данных используется для многих приложений, между элементами
этого набора устанавливается множество различных взаимосвязей, необходимых
для соответствующих прикладных программ. Организация базы данных в
значительной степени зависит от реализации взаимосвязей между элементами
данных и записями, а также от того, как и где эти данные хранятся. В базе
данных, используемой многими приложениями, должны быть установлены
многочисленные промежуточные взаимосвязи между элементами. В этом случае
при хранении и использовании данных контролировать их правильность,
обеспечивать их защиту и секретность труднее, чем при хранении данных в
простых, несвязанных файлах. Что касается обеспечения секретности данных и
восстановления их после сбоев, то этот вопрос является очень важным при
конструировании баз данных.
В некоторых системах средства управления базами данных применяются
для того, чтобы пользователи могли использовать данные таким путем, который
не был предусмотрен разработчиками системы. Администраторы или сотрудники
могут обращаться к вычислительной системе с вопросами, которые заранее в
ней не предусматривались. Наличие этой возможности означает такую
организацию данных в системе, при которой доступ к ним можно осуществлять
по различным путям, причем одни и те же данные могут использоваться для
ответов на различные вопросы. Вся существенная информация об объектах
запоминается одновременно и полностью, а не только та ее часть, которая
необходима для одного приложения. В настоящее время существуют СУБД,
реализующие эти возможности как на уровне локальных баз данных,
расположенных на одном диске (Paradox, Dbase), так и промышленных баз
данных (Acsess, Oracle, FoxPro).
Термины база данных (БД) и система управления базами данных (СУБД)
чаще всего употребляются как относящиеся к компьютерам. Понятие БД можно
применить к любой связанной между собой по определенному признаку
информации, хранимой и организованной особым образом - как правило, в виде
таблиц По сути. БД - это некоторое подобие электронной картотеки,
электронного хранилища данных, которое хранится в компьютере в виде одного
или нескольких файлов. При этом возникает необходимость в выполнении ряда
операций с БД. в первую очередь это:
* добавление новой информации в существующие файлы БД:
* добавление новых пустых файлов в БД:
* изменение (модификация) информации в существующих
файлах БД:
* поиск информации в БД:
* удаление информации из существующих файлов БД:
• удаление файлов из БД.
Компьютеризированная информационная система представляет собой
программный комплекс, задачи которого состоят в поддержке надежного
хранения БД в компьютере, выполнении преобразований информации и
соответствующих вычислений, предоставлении пользователям удобного и легко
осваиваемого интерфейса. Традиционно объемы информации, с которыми
приходится иметь дело таким системам, довольно велики, а сами БД имеют
достаточно сложную структуру. Примерами информационных систем являются
системы заказа железнодорожных или авиационных билетов, банковские системы
и многие другие.
2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ
С ростом популярности СУБД в 70-80-х годах появилось множество
различных моделей данных. У каждой из них имелись свои достоинства и
недостатки, которые сыграли ключевую роль в развитии реляционной модели
данных, появившейся во многом благодаря стремлению упростить и упорядочить
первые модели данных.
Современные БД основываются на использовании моделей данных (МД),
позволяющих описывать объекты предметных областей и взаимосвязи между
ними существуют три основные МД и их комбинации, на которых основываются
БД: реляционная модель данных (РМД), сетевая модель данных (СМД),
иерархическая модель данных (ИМД).
Основное различие между этими моделями данных состоит в способах
описания взаимодействий между объектами и атрибутами. Взаимосвязь
выражает отношение между множествами данных.
Используют взаимосвязи "один к одному", "один ко многим" и
"многие ко многим". "Один к одному" - это взаимно однозначное
соответствие, которое устанавливается между одним объектом и одним
атрибутом. "Один ко многим" - это соответствие между одним объектом и
многими атрибутами. "Многие ко многим" - это соответствие между многими
объектами и многими атрибутами.
2.1 Иерархическая модель данных
Иерархическая модель данных основана на понятии деревьев,
состоящих из вершин и ребер. Вершине дерева ставится в соответствие
совокупности атрибутов данных, характеризующих некоторый объект. Вершины
и ребра дерева как бы образуют иерархическую древовидную структуру,
состоящую из n уровней.
Первую вершину называют корневой вершиной. Он удовлетворяет
условиям:
1. Иерархия начинается с корневой вершины.
2. Каждая вершина соответствует одному или нескольким атрибутам.
3. Hа уровнях с большим номером находятся зависимые вершины. Вершин
предшествующего уровня является начальной для новых зависимых вершин.
4. Каждая вершина, находящаяся на уровне i, соединена с одной и только
одной вершиной уровня i-1, за исключением корневой вершины.
5. Корневая вершина может быть связана с одной или несколькими
зависимыми вершинами.
6. Доступ к каждой вершине происходит через корневую по единственному
пути
7. Существует произвольное количество вершин каждого уровня.
Иерархическая модель данных состоит из нескольких деревьев, т.е.
является лесом. Каждая корневая вершин образует начало записи логической
базы данных. В ИМД вершины, находящиеся на уровне i, называют
порожденными вершин ми н уровне i-1.
Операции в ИМД имеют нелогичный позаписный характер. Аппарат
перемещения по структуре в графовых моделях служит для установки тех
объектов данных, к которым будет применяться очередная операция
манипулирования данными. Такие объекты называются текущими. Механизмы
доступа к данным и перемещения по структуре данных в таких моделях
достаточно сложны и существенным образом опираются на концепцию текущего
состояния механизма доступа.
Основные достоинства ИМД: простота построения и
использования, обеспечение определенного уровня независимости данных,
простота оценки операционных характеристик. Основные недостатки:
отношение "многие ко многим" реализуется очень сложно, дает громоздкую
структуру и требует хранения избыточных данных, что особенно нежелательно
на физическом уровне, иерархическая упорядоченность усложняет операции
удаления и включения, доступ к любой вершине возможен только через
корневую, что увеличивает время доступа.
К числу СУБД иерархического типа можно отнести PCFocus,
Team-Up, Data Edge, также разработанную в нашей стране систему HИКА,
преемницу широко распространенной советской системы ИHЕС для ЕС ЭВМ.
Одной из наиболее важных сфер применения первых иерархических СУБД
было планирование производства для компаний, занимающихся выпуском
продукции. Например, если автомобильная компания хотела выпустить 10000
машин одной модели и 5000 машин другой модели, ей необходимо было знать,
сколько деталей следует заказать у своих поставщиков. Чтобы ответить на
этот вопрос, необходимо определить, из каких деталей состоят эти части и
т.д. Например, машина состоит из двигателя, корпуса и ходовой части;
двигатель состоит из клапанов, цилиндров, свеч и т.д. Работа со списками
составных частей была как будто специально предназначена для компьютеров.
Список составных частей изделия по своей природе является
иерархической структурой. Для хранения данных, имеющих такую структуру,
была разработана иерархическая модель данных, которую иллюстрирует рис.
2.1.
В этой модели каждая запись базы данных представляла конкретную
деталь. Между записями существовали отношения предокпотомок, связывающие
каждую часть с деталями, входящими в неё.
Чтобы получить доступ к данным, содержащимся в базе данных,
программа могла:
• найти конкретную деталь (правую дверь) по её номеру;
• перейти "вниз" к первому потомку (ручка двери);
• перейти "вверх" к предку (корпус);
• перейти "в сторону" к другому потомку (правая дверь).
Таким образом, для чтения данных из иерархической базы данных
требовалось перемещаться по записям, за один раз переходя на одну запись
вверх, вниз или в сторону.
Ограничения целостности.
Автоматически поддерживается целостность ссылок между предками и
потомками. Основное правило: никакой потомок не может существовать без
своего родителя. Заметим, что аналогичное поддержание целостности по
ссылкам между записями, не входящими в одну иерархию, не поддерживается.
В иерархических системах поддерживалась некоторая форма
представлений БД на основе ограничения иерархии.
2.2 Сетевая модель данных
Сетевая модель данных замышлялась как инструмент для
пользователей баз данных - программистов. В связи с этим в СМД больше
внимания уделяется структуризации данных, чем развитию ее операционных
возможностей.
В СМД элементарные данные и отношения между ними
представляются в виде ориентированной сети (вершины - данные, дуги -
отношения).
Если структура данных оказывалась сложнее, чем обычная иерархия,
простота структуры иерархической базы данных становилась её недостатком.
Например, в базе данных для хранения заказов один заказ мог участвовать в
трёх различных отношениях предокпотомок, связывающих заказ с клиентом,
разместившим его, со служащим, принявшим его, и с заказанным товаром, что
иллюстрирует рис. 2.2. Такие структуры данных не соответствовали строгой
иерархии IMS.
В связи с этим для таких приложений, как обработка заказов, была
разработана новая сетевая модель данных. Она являлась улучшенной
иерархической моделью, в которой одна запись могла участвовать в нескольких
отношениях предокпотомок. В сетевой модели такие отношения назывались
множествами. В 1971 году на конференции по языкам систем данных был
опубликован официальный стандарт сетевых баз данных, который известен как
модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую
СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах
независимые производители программного обеспечения реализовали сетевую
модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom
и СУБД Adabas, которые приобрели большую популярность.
Сетевые базы данных обладали рядом преимуществ:
• Гибкость. Множественные отношения предокпотомок позволяли сетевой базе
данных хранить данные, структура которых была сложнее простой иерархии.
• Стандартизация. Появление стандарта CODASYL популярность сетевой модели,
а такие поставщики мини-компьютеров, как Digital Equipment Corporation и
Data General, реализовали сетевые СУБД.
• Быстродействие. Вопреки своей большой сложности, сетевые базы данных
достигали быстродействия, сравнимого с быстродействием иерархических баз
данных. Множества были представлены указателями на физические записи
данных, и в некоторых системах администратор мог задать кластеризацию
данных на основе множества отношений.
Конечно, у сетевых баз данных были недостатки. Как и иерархические
базы данных, сетевые базе данных были очень жесткими. Наборы отношений и
структуру записей приходилось задавать наперёд. Изменение структуры базы
данных обычно означало перестройку всей базы данных.
Как иерархическая, так и сетевая база данных были инструментами
программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее
часто заказывает компания Acme Manufacturing?", программисту приходилось
писать программу для навигации по базе данных. Реализация пользовательских
запросов часто затягивалась на недели и месяцы, и к моменту появления
программы информация, которую она предоставляла, часто оказывалась
бесполезной.
Ограничения целостности.
В принципе их поддержание не требуется, но иногда требуют
целостности по ссылкам (как в иерархической модели).
2.3 Реляционная модель данных
Недостатки иерархической и сетевой моделей привели к появлению
новой, реляционной модели данных, созданной Коддом в 1970 году и вызвавшей
всеобщий интерес. Реляционная модель была попыткой упростить структуру базы
данных. В ней отсутствовали явные указатели на предков и потомков, а все
данные были представлены в виде простых таблиц, разбитых на строки и
столбцы. На рис. 2.3. показана реляционная версия сетевой базы данных,
содержащей информацию о заказах и приведенной на рис. 2.2.
К сожалению, практическое определение понятия "реляционная база
данных" оказалось гораздо более расплывчатым, чем точное математическое
определение, данное этому термину Коддом в 1970 году. В первых реляционных
СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот
пробел был восполнен только впоследствии. По мере роста популярности
реляционной концепции реляционными стали называться многие базы данных,
которые на деле таковыми не являлись.
В ответ на неправильное использование термина "реляционный" Кодд в
1985 году написал статью, где сформулировал 12 правил, которым должна
удовлетворять любая база данных, претендующая на звание реляционной. С тех
пор двенадцать правил Кодда считаются определением реляционной СУБД. Однако
можно сформулировать и более простое определение:
Реляционной называется база данных, в которой все данные, доступные
пользователю, организованны в виде таблиц, а все операции над данными
сводятся к операциям над этими таблицами.
Приведенное определение не оставляет места встроенным указателям,
имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД
также способна реализовать отношения предокпотомок, однако эти отношения
представлены исключительно значениями данных, содержащихся в таблицах.
Таблица рассматривается как непосредственное хранилище данных.
Традиционно в реляционных системах таблицу называют отношением. Строку
таблицы называют кортежем, а столбец - атрибутом. При этом атрибуты имеют
уникальные (в пределах отношения) имена. Количество кортежей в таблице
называют кардинальным числом, а количество
атрибутов - степенью. Для отношения предусматривают уникальный
идентификатор, то есть один или несколько атрибутов, значения которых в
одно и то же время не бывают одинаковыми - идентификатор называют первичным
ключом. Домен - это множество допустимых однородных значений для того или
иного атрибута. Таким образом, домен можно рассмотреть как именованное
множество данных, причем составные части этого множества являются логически
неделимыми единицами (в качестве домена могут выступать, например, перечень
фамилий сотрудников учреждения, однако не все фамилии могут присутствовать
в таблице).
Отношение содержит две части - заголовок и собственно содержательную
часть. Заголовок содержит конечное множество атрибутов, а содержательная
часть (тело отношения) – множество пар имени атрибута и его значения.
Например, KOD, NAME и SUMM, содержащиеся в заголовке, являются атрибутами,
а скажем, пары SUMM - 25.50 или KOD - 5216 являются элементами тела
отношения.
2.3.1 Атрибуты
Первичный ключ
В реляционных БД, в отличие от других моделей, пользователь
указывает, какие данные для него необходимы, а не то, как это делать. По
этой причине процесс перемещения и навигации по БД в реляционных системах
является автоматическим, а эту задачу в таких СУБД выполняет так называемый
оптимизатор. Его работа заключается, например, в том, чтобы наиболее
эффективным способом произвести выборку данных из БД по запросу Таким
образом, оптимизатор, по крайней мере, должен суметь определить, из каких
таблиц выбираются данные, насколько много информации в этих таблицах, каков
физический порядок записей в таблицах ... продолжение
Похожие работы
Дисциплины
- Информатика
- Банковское дело
- Оценка бизнеса
- Бухгалтерское дело
- Валеология
- География
- Геология, Геофизика, Геодезия
- Религия
- Общая история
- Журналистика
- Таможенное дело
- История Казахстана
- Финансы
- Законодательство и Право, Криминалистика
- Маркетинг
- Культурология
- Медицина
- Менеджмент
- Нефть, Газ
- Искуство, музыка
- Педагогика
- Психология
- Страхование
- Налоги
- Политология
- Сертификация, стандартизация
- Социология, Демография
- Статистика
- Туризм
- Физика
- Философия
- Химия
- Делопроизводсто
- Экология, Охрана природы, Природопользование
- Экономика
- Литература
- Биология
- Мясо, молочно, вино-водочные продукты
- Земельный кадастр, Недвижимость
- Математика, Геометрия
- Государственное управление
- Архивное дело
- Полиграфия
- Горное дело
- Языковедение, Филология
- Исторические личности
- Автоматизация, Техника
- Экономическая география
- Международные отношения
- ОБЖ (Основы безопасности жизнедеятельности), Защита труда