Автоматизация системы учета заказов на предприятии

30

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

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

ДИПЛОМНЫЙ ПРОЕКТ

АВТОМАТИЗАЦИЯ СИСТЕМЫ УЧЕТА ЗАКАЗОВ НА ПРЕДПРИЯТИИ

Календарный график выполнения дипломного проекта

Наименование этапов дипломного проекта	Срок выполнения этапов проекта	Примечание
1. Аналитическая часть. Анализ и выбор метода решения задачи "Автоматизация учета заказов на ООО "Кортереал"
Разработка реляционной базы данных для учета заказов на ООО «Кортереал»
3. Разработка программного комплекса учета заказов на ООО «Кортереал» средствами Microsoft Access.
4 Анализ надежности и экономической эффективности разработанной системы учета заказов.
5 Оформление дипломного проекта и сдача его на кафедру

РЕФЕРАТ

БАЗЫ ДАННЫХ, ACCESS, ИНФОЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ, ОБЪЕКТ, НОРМАЛИЗАЦИЯ, ЯЗЫК SQL,ВИЗУАЛЬНЫЕ КОМПОНЕНТЫ, МОДЕЛИ ДАННЫХ, УЧЕТ.

Целью работы является разработка программного обеспечения для автоматизации процесса учета поступления и формирования заказов - базы данных, реализующей хранение данных, организацию доступа к ним и редактирование. Методом выполнения работы является построение реляционной базы данных средствами Microsoft Access. Результатом выполнения работы является создание программного обеспечения “База данных учета заказов” и его внедрение на предприятии ООО «Кортереал».

Область применения разработанного программного комплекса - коммерческая деятельность ООО «Кортереал», повышение эффективности организации информационных потоков на предприятии.

Содержание

Введение

Глава 1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Кортереал»

1.1 Анализ существующей на предприятии системы учета заказов

1.2 Принципы построения инфологических моделей

1.3 Инфологическая модель задачи автоматизации заказов

1.4 Анализ ключей сущностей проектируемой базы данных

1.5 Выбор методики и технических средств реализации базы данных

Глава 2. Разработка базы данных по учету заказов на ООО «Кортереал» с использованием пакета Microsoft Access

2.1 Процедура проектирования реляционной базы данных

2.2 Разработка и нормализация системы таблиц базы данных

2.3 Разработка форм для обработки информации в базе данных

2.4 Разработка механизма оформления заказов в базе дынных

2.5 Разработка средств анализа в базе данных ООО «Кортереал»

2.6 Разработка системы отчетов базы данных

Глава 3. Оценка надежности и экономической эффективности системы учета заказов на ООО «Кортереал»

3.1 Выбор метода оценки надежности базы данных ООО «Кортереал»

3.2 Расчет надежности системы учета заказов на ООО «Кортереал»

3.3 Оценка экономической эффективности внедрения системы учета заказов на ООО «Кортереал»

Заключение

Список использованной литературы

Приложения

Введение

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

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

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

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

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

Общепринятыми в настоящее время являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Стандартом «де-факто» стала «быстрая разработка приложений» или RAD, основанная на «открытом подходе». Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

Приложение Microsoft Access является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (СУБД). Access - мощное приложение Windows. При этом производительность СУБД органично сочетаются со всеми удобствами и преимуществами Windows. Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Access специально спроектирован для создания многопользовательских приложений, где файлы базы данных являются разделяемыми ресурсами в сети. В Access реализована надёжная система защиты от несанкционированного доступа к файлам. Целью данной дипломной работы является разработка базы данных с использованием средств Microsoft Access для автоматизации процедур учета и формирования заказов на предприятии ООО «Кортереал», занимающемся оптовой и розничной реализацией картографической продукции. Задачами, решаемыми при выполнении поставленной задачи, являются:

-- анализ системы документооборота на ООО «Кортереал»;

-- построение инфологической модели учета заказов;

-- разработка даталогической модели системы учета заказов на предприятии с использованием средств Microsoft Access;

-- практическая разработка программного комплекса учета и контроля заказов средств Microsoft Access;

-- анализ надежности созданного программного продукта;

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

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

Глава 1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Кортереал»

1.1 Анализ существующей на предприятии системы учета заказов

Общество с ограниченной ответственностью «Кортереал» расположено в г. Ростове. Юридический адрес предприятия: г.Ростов, ул. Гражданская, 24 стр. 1. Численность работающего на предприятии персонала составляет 22 человека. ООО «Кортереал» занимается оптовой и розничной реализацией картографической продукции, в том числе это атласы, сборники топографических карт, судоходные карты, компьютерные диски и программы соответствующей тематики. Фирма сотрудничает с несколькими крупными издательствами в России и за рубежом, а также с крупными оптовыми поставщиками продукции соответствующей тематики. Фирма имеет в г.Ростове довольно крупный оптовый склад, на котором производится накопление и распределение товаров в соответствии с полученными заявками.

При этом более 90% продаж фирмы являются оптовыми, причем география продаж оказывается очень широкой, многие деловые партнеры ООО «Кортереал» находятся за рубежом. Среди постоянных клиентов фирмы несколько крупных судоходных компаний, геологоразведочные организации, туристические бюро и даже операторы сотовой связи (они приобретают электронные топографические карты с привязкой к существующим навигационным системам) и, конечно, книготорговые сети. Среди частных клиентов реализуется незначительная часть товарных запасов (менее 10%). Основной источник заказов частных лиц - Интернет-сайт ООО «Кортереал» и система приема заказов «Книга - Почтой».

Объемы продаж имеют устойчивую тенденцию к росту, постоянно расширяется география как клиентов, так и поставщиков предприятия. В 2011 году было реализовано продукции на 24,4 млн. руб., всего порядка 110 тыс. экземпляров книг, атласов и сборников карт, что составило 14560 выполненных заказов. Это на 8,6 % больше, чем в предыдущем, 2010 году.

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

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

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

Наиболее слабыми местами в данной схеме работы являются:

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

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

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

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

1.2 Принципы построения инфологических моделей

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

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

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

Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных. [5, стр. 42-43].

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

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты) [31, стр. 28-30].

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

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

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

Связь - ассоциирование двух или более сущностей.

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь) [31, стр.39]. В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение. Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Как правило, определяются три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения. [25, стр.76-77].

Стержневая сущность (стержень) - это независимая сущность.

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности.

Ассоциации рассматриваются как полноправные сущности:

- они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;

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

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

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

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

1.3 Инфологическая модель задачи автоматизации заказов

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

Нам также потребуется сущность ТОВАРЫ, которая является обозначающей для сущности ПОСТАВЩИК.

Для характеристики сущности КЛИЕНТЫ используется сущность ЗАКАЗ, поскольку заказ возникает только после того, как один из клиентов оформит его на фирме. Эта же сущность используется для характиристики и другой стержневой сущности - СОТРУДНИКИ, т.к. именно сотрудники выполняют все действия, связанные с обслуживанием полученного заказ.

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

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

Итак, рассмотрим сначала сущность ПОСТАВЩИК. Конечно, возможно связать с этой сущностью очень много атрибутов, но нам следует выделить только те, которые касаются всех участников процесса продаж на ООО «Кортереал». Таких атрибутов не так уж и много:

Название поставщика (все поставщики - фирмы или частные предприниматели, имеющие фирменное наименование)

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

Город поставщика

Область поставщика

Индекс поставщика

Страна поставщика

Телефон поставщика (с кодом страны или региона)

Факс поставщика (с кодом страны или региона)

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

Ключевым полем сущности разумно считать уникальный код Поставщика.

Далее рассмотрим обозначающую сущность ТОВАРЫ. Ей присущи следующие обязательные атрибуты:

Наименование товара

Единица измерения товара

Цена товара

Наличие товара на складе (данный атрибут должен выражаться неотрицательным целым числом)

Возможность заказать товар у Поставщика (данный атрибут проще всего представить в логической форме - поставки прекращены или есть возможность заказа товара).

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

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

Рассмотрим стержневую сущность КЛИЕНТЫ. По сути, это база клиентов, разместивших заказы на фирме. Атрибутами сущности являются:

Название клиента

Контактное лицо по заказу (особенно это важно при работе с крупными заказчиками, фирмами).

Адрес клиента

Город клиента

Область клиента

Индекс клиента

Страна клиента

Телефон клиента (с кодом страны или региона)

Факс клиента (с кодом страны или региона)

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

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

Фамилия, имя и отчество сотрудника

Пол сотрудника

Должность сотрудника

Дата рождения сотрудника

Адрес сотрудника

Город сотрудника

Область сотрудника

Индекс сотрудника

Страна сотрудника (атрибуты 5-9 существенны, поскольку сотрудники ООО «Кортереал» работают и в других городах и даже за рубежом)

Домашний телефон сотрудника (с кодом страны или региона)

Мобильный телефон сотрудника (с кодом страны или региона)

Общие сведения о сотруднике

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

Сущность ЗАКАЗ является харакетристикой сущностей КЛИЕНТЫ и СОТРУДНИКИ. Её атрибутами являются:

Уникальный код клиента, разместившего заказ

Уникальный код сотрудника, обслуживающего заказ

Дата размещения заказа

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

Адрес получателя

Город получателя

Индекс получателя

Область получателя

Страна получателя

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

Последней сущностью, которую следует проанализировать, является ассоциативная сущность ЗАКАЗАНО. Её атрибутами являются:

Код заказанного товара

Цена товара в заказе

Количество товара в заказе

Предоставленная скидка

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

По результатам проведенного анализа легко видеть, что все рассматриваемые сущности обладают уникальным кодом и этот код является простым, т.е. содержащим только один атрибут сущности. Для того, чтобы впоследствии эффективно работать с заявленными сущностями, необходимо точно указать, каким типом данных выражается тот или иной атрибут сущности и каков его размер при размещении в базе данных. Также важно для атрибутов установить, обязательными ли они являются для данной сущности и возможны ли повторения для данных атрибутов [14, стр.112]. Проведя анализ имеющихся записей у менеджеров, работающих с клиентами и менеджера склада, можно дать соответствующие оценки. Итоговые данные по сущностям, используемым в инфологической модели базы данных, приведены в Приложении А. Модель на языке ЯИМ имеет следующий вид:

ПОСТАВЩИКИ(КодПоставщика, Название, Адрес, Город, Область, Индекс, Страна, Телефон, Факс)

ТОВАРЫ (КодТовара, Наименование, КодПоставщика, ЕдиницаИзмерения, Цена, НаСкладе, ПоставкиПрекращены) [ПОСТАВЩИКИ]

ЗАКАЗ (КодЗаказа, КодКлиента, КодСотрудника, ДатаРазмещения, НазваниеПолучателя, АдресПолучателя, ГородПолучателя, ИндексПолучателя, ОбластьПолучателя, СтранаПолучателя) {КЛИЕНТЫ, СОТРУДНИКИ}

СОТРУДНИКИ (КодСотрудника, ФИО, Пол, Должность, ДатаРождения, Адрес, Город, Область, Индекс, Страна, ДомашнийТелефон, Мобильный Телефон, Примечание) ЗАКАЗАНО [Товары М, Заказы N] (КодЗаказа, КодТовара, Цена, Количество, скидка)КЛИЕНТЫ (КодКлиента, Название, ОбращатьсяК, Адрес, Город, Область, Индекс, Страна, Телефон, Факс) Теперь мы можем построить инфологическую модель базы данных по учету заказов на ООО «Кортереал» с использованием описанного в предыдущем параграфе языка ER-диаграмм:

1.4 Анализ ключей сущностей проектируемой базы данных

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

Теперь о внешних ключах:

- Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

- Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

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

1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом?

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку.

Существует три возможности [12, стр.65-67]:

КАСКАДИРУЕТСЯ	Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика.
ОГРАНИЧИВАЕТСЯ	Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Имеются те же три возможности, как и при удалении:

КАСКАДИРУЕТСЯ	Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ впоставках этого поставщика.
ОГРАНИЧИВАЕТСЯ	Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

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

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

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

Указанные спецификации представляют зависимость по существованию характеристических сущностей. В ситуации с рассмотренными выше сущностями базы данных ООО «Кортереал» имеют место следующие общие наблюдения:

Сущность ПОСТАВЩИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( КодПоставщика )

ПОЛЯ (КодПоставщика, Название, Адрес, Город, Индекс,Страна,Телефон, Факс);

Сущность СОТРУДНИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( КодСотрудника )

ПОЛЯ (КодСотрудника, ФИО, Пол, Должность, ДатаРождения, Адрес, Город, Индекс,Страна,ДомашнийТелефон, МобильныйТелефон, Примечания);

Сущность КЛИЕНТЫ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( КодКлиента )

ПОЛЯ (КодКлиента, Название,ОбращатьсяК, Адрес, Город, Область,Индекс, Страна, Телефон, Факс);

Сущность ТОВАРЫ *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( КодТовара )

ВНЕШНИЙ КЛЮЧ ( КодПоставщика ИЗ ПОСТАВЩИКИ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПОСТАВЩИКИ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПОСТАВЩИКИ.КодПоставщика ОГРАНИЧИВАЕТСЯ)

ПОЛЯ (КодТовара, КодПоставщика, Наименование, ЕдиницаИзмерения, Цена, НаСкладе, ПоставкиПрекращены)

ОГРАНИЧЕНИЯ ( Значения полей КодПоставщика должны принадлежать набору значений соответствующих полей сущности ПОСТАВЩИКИ; при нарушении вывод предупреждающего сообщения);

Сущность ЗАКАЗ *( Характеризует СОТРУДНИКИ и КЛИЕНТЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( КодЗаказа )

ВНЕШНИЙ КЛЮЧ ( КодКлиента ИЗ КЛИЕНТЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ КЛИЕНТЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ КЛИЕНТЫ.КодКлиента КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( КодСотрудника ИЗ СОТРУДНИКИ

NULL-значения ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ СОТРУДНИКИ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ СОТРУДНИКИ.КодСотрудника КАСКАДИРУЕТСЯ)

ПОЛЯ ( КодЗаказа,КодКлиента, КодСотрудника, ДатаРазмещения, НазваниеПолучателя, АдресПолучателя, ГородПолучателя, ИндексПолучателя,ОбластьПолучателя, СтранаПолучателя )

ОГРАНИЧЕНИЯ ( Значения поля КодКлиента должны принадлежать набору значений соответствующего поля сущности КЛИЕНТЫ, значение поля КодСотрудника либо пусто,либо принадлжит набору значений соответствующего поля сущности СОТРУДНИКИ; при нарушении вывод сообщения);

Сущность ЗАКАЗАНО *( Связывает ТОВАРЫ и ЗАКАЗЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( КодЗаказа, КодТовара )

ВНЕШНИЙ КЛЮЧ ( КодЗаказа ИЗ ЗАКАЗЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ЗАКАЗЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ЗАКАЗЫ.КодЗаказа КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( КодТовара ИЗ ТОВАРЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ТОВАРЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ТОВАРЫ.КодТовара КАСКАДИРУЕТСЯ)

ПОЛЯ ( КодЗаказа,КодТовара, Цена,Количество, Скидка )

ОГРАНИЧЕНИЯ ( Значения полей КодЗаказа и КодТовара должны принадлежать набору значений соответствующих полей сущностей ЗАКАЗЫ и ТОВАРЫ; при нарушении вывод сообщения);

1.5 Выбор методики и технических средств реализации базы данных

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

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

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

Поскольку на ООО «Кортереал» в настоящее время немного сотрудников (фактически доступ к проектируемой базе данных необходимо обеспечить для девяти человек), а количество записей в базе ограничивается несколькими тысячами, то наиболее приемлемым и простым с точки зрения реализации на данном предприятии способом обработки данных является централизованная база данных. Существующая на предприятии локальная сеть (100 Мб/сек) обеспечивает быстрый доступ всех заинтересованных сотрудников к базе данных, а мощности используемых ПК вполне хватает для быстрой обработки всех возможных запросов. По способу доступа проектируемая база, несомненно, является базой с сетевым доступом. Более того, должна быть реализована возможность работы с базой данных через Интернет, что позволяет решить две важные проблемы:

-- обеспечение работы с базой для удаленно работающих сотрудников

-- возможность размещения заказов клиентами непосредственно через Интернет в режиме реального времени.

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

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

Если какая-либо прикладная информационная система опирается на некоторую систему управления данными, обладающую этими функциями, то эта система управления данными является системой управления базами данных (СУБД). СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве [8, стр. 109]. Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели [8].

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

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

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

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

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

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

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

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

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

Обоснование выбора СУБД и средств разработки прикладного программного обеспечения.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу [18, стр. 63]. Требования, предъявляемые к современным СУБД:

Поддержка определённой логической модели данных.

Наличие встроенных языковых средств, в том числе:

а) язык определения данных - Data Definition Language(DDL).

б) языки манипулирования данных - Data Manipulation Language(DML).

в) язык запросов - Query Language(QL).

Наличие графического интерфейса, в котором можно выделить: интерфейс пользователя(User Interface), интерфейс разработчика(Developer Interface), интерфейс администратора(Administrator Interface).

Наличие подсистемы словаря данных и системного каталога.

Наличие программных средств контроля целостности данных.

Наличие средств разграничения доступа к данным.

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

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

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. В Access существуют средства просмотра и манипулирования объектами базы данных [9, стр. 34-37]:

- панель инструментов позволяет быстро выполнять команды создания, открытия и управления объектами базы данных;

- полоса объектов, предназначенная для просмотра объектов БД. Ее вертикальное расположение более удобно в использовании;

- ярлыки в окне базы данных ускоряют создание объектов с помощью Мастеров или открытие новых объектов в режиме Конструктора:

- настройка способов выбора и открытия объектов в окне базы данных;

К существующим возможностям, облегчающим работу с данными и проектирование базы данных, в среде Microsoft Access относятся следующие:

- поддерживается блокировка на уровне записей в дополнение к обычной блокировке, которая блокировала все записи на 4-кбайтной странице;

- можно свободно перемещаться между диалоговыми окнами поиска, замены и работы с данными;

- возможен просмотр и редактирование связанных записей в режиме таблицы (subdatasheet);

- автоматическое обнаружение ошибок переименования позволяет корректировать общие ошибки, вызванные переименованием форм, отчетов, таблиц, запросов, полей, текстовых боксов (text boxes) и других элементов управления;

- поддержка 16-разрядного стандарта кодировки символов Unicode;

- использование Microsoft ActiveX Data Objects (ADO) для доступа и манипулирования данными в базах данных сервера.

Microsoft Access предоставляет максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Можно задать также форматы хранения и представления этих данных при выводе на экран или печать. Microsoft Access может работать с большим числом самых разнообразных форматов данных, включая файловые структуры других СУБД. Можно осуществлять импорт и экспорт данных из файлов текстовых редакторов или электронных таблиц. С помощью Access вы можете непосредственно обрабатывать файлы Paradox, dBASE III, dBASE IV, Btrieve, FoxPro и др. В Microsoft Access для обработки данных ваших таблиц используется мощный язык SQL (Structured Query Language -- Структурированный язык запросов). Используя SQL, можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. При любой обработке данных из нескольких таблиц Access использует однажды заданные вами связи между таблицами [4, стр. 82-85].

Microsoft Access спроектирован таким образом, что он может быть использован как в качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети -- в режиме «клиент -- сервер». Поскольку в Access к данным могут иметь доступ одновременно несколько пользователей, в нем предусмотрены надежные средства защиты и обеспечения целостности данных. Можно заранее указать, какие пользователи или группы пользователей могут иметь доступ к объектам (таблицам, формам, запросам) к базам данных. Access автоматически обеспечивает защиту данных от одновременной их корректировки разными пользователями, в Access имеются средства, позволяющие легко проектировать и создавать приложения для работы с базами данных без знания языка программирования. Работа в Access начинается с определения реляционных таблиц и их полей, которые будут содержать данные. Microsoft Access предоставляет дополнительные средства разработки приложений, которые могут работать не только с собственными форматами данных, но и с форматами других наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access является его способность обрабатывать данные электронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой базы данных SQL, поддерживающей стандарт ODBC. Это означает, что можно использовать Access для создания такого приложения Windows, которое может обрабатывать данные, поступающие с сетевого сервера SQL или базы данных SQL на сервере [29, стр. 90-93].

Таким образом, для построения эффективно работающей базы данных по учету заказов на ООО «Кортереал» целесообразно использовать Microsoft Access, работающий в режиме клиент-серверного приложения. Существующая на предприятии локальная сеть полностью обеспечивает эффективную работу данного программного продукта, а разработка базы данных на базе Access является в настоящее время наиболее дешевым решением задачи, не требующем привлечения квалифицированных специалистов для решения сложных задач программирования.

Глава 2. Разработка базы данных по учету заказов на ООО «Кортереал» с использованием пакета Microsoft Access

2.1 Процедура проектирования реляционной базы данных

Процесс проектирования информационных систем является достаточно сложной задачей. Он начинается с построения инфологической модели данных (п. 2), т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги процедуры проектирования даталогической модели [14, стр. 117-124].

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

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

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

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

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

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

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

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.

На рисунке 2.1. показан синтаксис предложения, предлагаемого для регистрации принимаемых проектных решений [12].

Рисунок 2.1. - Синтаксис описания проектных решений

2.2 Разработка и нормализация системы таблиц базы данных

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

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

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

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

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

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

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

Следовательно, должны быть созданы таблицы Поставщики, Товары, Заказано, Заказы, Сотрудники, Клиенты, удовлетворяющие требованиям, сформулированным для соответствующих сущностей и приведенным в Приложении А. Однако, прежде чем мы будем использовать данные таблицы для разработки программного продукта средствами Microsoft Access, следует убедиться, что набор исходных таблиц является нормализованным, если же это не так, следует нормализовать его для обеспечения целостности базы данных и отсутствия ошибок при обработке данных.

Нормализация - это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации [12, стр. 188-190].

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