Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Структура даних

Найважливішим елементом будь-якої бази даних, незалежно від її подання, є структура даних, яка відображає можливі подання відомостей для зберігання, вибірки і обробки. Структури даних необхідні для роботи з документарними даними, не пов'язаними з комп'ютерною обробкою, і зданими, що подаються в автоматизованих системах.

У сенсі під термінів "Структура даних" розуміється одиниця відомостей, що дозволяє зберігати і обробляти безліч однотипних і (або) логічно пов'язаних даних

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

Фактичне поява терміна "Структура даних" засноване на необхідності документарного подання відомостей і виникненні документа в якості джерела і засоби передачі інформації, що знайшло відображення у виникненні правил оформлення документів та подання в них відомостей.

Структурованість документів, підпорядкована певним правилам, дозволяє людині краще розуміти особливості внесення в документ даних. Так, наприклад, документ "Товарний чек" (рис. 1.7) містить вказівку на необхідність відображення найменування організації в нулі "Фірма". Розуміння суті даної характеристики і знань правил заповнення бухгалтерських документів дає можливість продавцеві правильно заповнити поле документа, вказавши не тільки найменування організації, по і її організаційно-правову форму у відповідність з даними в установчих та реєстраційних документах (статут, свідоцтво про реєстрацію організації) ТОВ " електроніка ".

image7

Мал. 1.7. Приклад структури даних у вигляді документа


Поряд з полем "Фірма" в представленому прикладі документа вказано ряд інших характеристик - "Дата", "Найменування товару", "Кількість", "Ціна", "Сума", "Всього". Частина з зазначених характеристик представляють незалежними атрибутами, припускаючи вказівку незв'язаних з іншими характеристиками даних. Деякі характеристики ( "Найменування товару", "Кількість", "Ціна", "Сума") є взаємопов'язаними атрибутами, що характеризують проданий товар і представленими в певній структурі, даючи зрозуміти продавцю, що необхідно по кожному товару вказати додаткові характеристики, які мають до нього відношення , розкриваючи повну інформацію про проведену торгової операції. При цьому, варто зауважити, що одна з характеристик ( "Сума") є обчислюється характеристикою, що залежить від значень двох характеристик в рядку таблиці ( "Кількість", "Ціна"). Ця характеристика обчислюється але цілком визначеною формулою шляхом перемноження значення колонки "Кількість" на значення колонки "Ціна" в рамках кожної заповненого рядка таблиці даних про товари.

Ще одна характеристика ( "Всього"), яка присутня в документі, має особливі властивості. Ця характеристика, розташована внизу таблиці з даними про продані товари, говорить продавцеві про необхідність порахувати загальну суму але всім проданих товарів, формуючи агреговані відомості фінансового характеру. Потрібно звернути увагу на розміщення і форму подання даної характеристики. Структура даних документа ясно дасть зрозуміти, що в цьому иоле повинна відображатися тільки одна агрегована характеристика, а оскільки документ відноситься до фінансових, то ця характеристика відображає саме фінансові відомості - загальну суму але проданих товарів.

Однак, якщо цю характеристику внести в структуру таблиці і розділити на відповідні таблиці колонки ( "Кількість", "Сума"), то характеристика поміняє свою суть і постане в формі групової агрегированной характеристики, яка передбачає вказівку загальної кількості проданих одиниць товарів (при можливості проведення даної операції, враховуючи одиниці виміру кількості товару) і загальної вартості. Природно, що, читаючи структуру документа, продавець, грунтуючись на умовах і правилах роботи з документом, заповнює тільки тими значеннями відповідні характеристики, які об'єктивно доцільні для заповнення.

Таким чином, структура даних документа "Товарний чек", враховуючи правила відображення та обробки окремих відомостей в даній структурі, дасть продавцеві вичерпну інформацію про внесені в документ даних.

На прикладі документа видно, що для опису структур даних використовується ряд елементів, що відбивають складові таких структур. Одним з таких елементів є атрибут, який по мірі розвитку технологій роботи з даними став базовим, що відображає характеристику відомостей.

Під терміном "Атрибут" розуміють необхідне існування властивість об'єкта.

Це визначення є загальновживаним з філософської точки зору, але добре відображає суть терміна в загальному його розумінні. Поширюючи його на роботу з даними, можна говорити про його розгляді в якості основного елемента, який дозволяє, з урахуванням знань і предметної області, описати не тільки характеристическую сутність об'єкта, по і відобразити форму і особливості подання. Звичайно, не кожна характеристика об'єкта може бути настільки однозначно інтерпретуватися атрибутом, але при правильному іменуванні атрибута, як правило, це можливо зробити.

Таким чином, з точки зору роботи з даними під терміном "Атрибут" слід розуміти характеристичне властивість об'єкта, що відбиває окреме смислове значення об'єкта.

Правильне виділення атрибутів для опису характеристик об'єкта є однією з найскладніших завдань в розробці баз даних, оскільки часто складно визначити необхідність використання тієї чи іншої характеристики при поданні даних про об'єкт.

Так, наприклад, при розгляді об'єкта "Товар" виникає питання, наскільки необхідно в базі даних відображати такі характеристики: "Найменування", "Артикул", "Ціна придбання", "Кількість поставки", "Колір", "Розмір" і т. д. Очевидно, що на вибір використовуваних атрибутів впливає кілька факторів, до яких можна віднести сферу даної діяльності (склад, магазин і ін.), Види товарів для зберігання даних (взуття, одяг, комп'ютери, продукти і т.д.), з метою зберігання даних (аналітична обробка надходжень товарів, облік наявних товарів на складі або в магазині, публікація каталогу товарів і т.д.), багато інших.

До того ж, важливим є правильність найменування атрибута, що дозволяє без зайвого додаткового аналізу однозначно інтерпретувати зазначену в атрибуті характеристику. Як правило, в аналізованих документах, при побудові бази даних, вже вказані необхідні найменування, але документ являє цілісну структуру даних, яка дозволяє точно виділити необхідні характеристики об'єкта.

Наприклад, в документі на рис. 1.7 атрибут документа "Ціна" може бути однозначно інтерпретований як "Ціна товару, що продається", хоча це і не написано в самому документі. Визначити це можна з самої структури документа. Даний атрибут розміщений в документі "Товарний чек", який видається клієнту при продажу товару, а значить, мова в документі буде йти про що продаються товари. Також цей атрибут розміщений в документі в рамках таблиці, де поруч розміщені і пов'язані з ним інші атрибути: "Найменування", "Кількість", "Сума". З огляду на те, що мова в документі йде про товари, які є основними елементами даних, то однозначно зрозумілі можливі значення в таблиці документа. Оскільки одним з атрибутів рядків в таблиці є характеристика "Найменування", то при розгляді атрибута "Ціна" стає зрозуміло, що мова йде про ціну товару, вказаного своїм найменуванням у відповідному рядку таблиці. В результаті, інтерпретація атрибута "Ціна" розуміється однозначно.

Але для подання атрибута в базі даних таке іменування атрибута може виявитися неможливим, оскільки на нього впливає не тільки місце розташування (сутність моделі бази даних), а й розміщення інших атрибутів в цій же сутності (рис. 1.8).

image8

Мал. 1.8. Приклад вказівки атрибутів в сутності


Уявімо, що по суті моделі бази даних "Товар на складі" вказані два атрибути: "Ціна" і "Дата". Найменування суті "Товар на складі" дозволяє зрозуміти, що у відповідному елементі бази даних буде зберігатися інформація про товари, які розміщені на складі, але немає жодної вказівки на те, яким статусом будуть володіти ці товари: придбані, продані, переучтенние і т.д . Наявність атрибута "Дата" не дає однозначної інтерпретації суті врахованих товарів, оскільки під цим атрибутом можна розуміти дату придбання, дату вибуття, дату переобліку і т.д. У такому ж невизначеному стані знаходиться атрибут "Ціна". Для того щоб зрозуміти суть цих двох характеристик, необхідно повернутися до аналізу предметної області і зрозуміти суть ставляться для інформаційної системи завдань.

Уточнимо зазначені атрибути і додамо новий атрибут, пов'язаний з атрибутом "Дата" (рис. 1.9). Тепер атрибут "Ціна придбання" дозволяє зрозуміти, що цей атрибут однозначно інтерпретуємо і відображає цепу, по якій був придбаний товар, а атрибут "Дата" не має до нього ніякого відношення і характеризує переоцінку товарів у певний період. Додавання атрибута "Ціна поточна" уточнює опис об'єкта "Товар на складі". У попередньому варіанті моделі неможливо було вказати цей атрибут, що не доповнивши його поняттям "поточна". Его призвело б до появи двох атрибутів з ідентичними назвами, що тільки ускладнить розуміння суті збережених даних. Уточнення атрибута в найменування "Ціна поточна" в зв'язці з атрибутом "Дата переоцінки" однозначно може бути інтерпретовано в розуміння того, що тут будуть зберігатися відомості про поточну ціну товару на момент його переоцінки, а ціна придбання в усі дати переоцінки товару буде залишатися незмінною.

Іншим елементом структури даних в документі є "Тип даних". Цей елемент в явному вигляді в документі не представлено, але розуміння предметної області і логічний аналіз використовуваних атрибутів дозволяють з високою ймовірністю бути впевненим в тому, які дані

і якого типу повинні бути представлені у відповідних місцях документа.

image9

Мал. 1.9. Уточнення атрибутів по суті


По суті, тип даних визначає форму і правила подання певних даних. Як форма тип даних визначає можливе використання символів в написанні даних. Для рядка і тексту такими можуть виступати будь-які символи від цифр до букв і спеціальних символів. Для числового типу даних використовуються тільки цифри і знак "," як роздільник цілої та дробової частини. Логічний тип даних може представлятися різними варіантами, в залежності від обраної СУБД: "Істина" або "Брехня", "True" або "False", 1 або 0 і т.д. Правила для типу даних визначають закони, за якими дані повинні бути виведені в документ або на екран комп'ютера. Для символьно-числового типу даних таким правилом може бути необхідність виведення числового значення з можливістю подання ведучого знака "О" (наприклад, БИК банку представляється значенням "044525225").

Під терміном "Тип даних" розуміється характеристичне властивість атрибута, що визначає форму, розмір та правила подання даних.

Якщо розглянути атрибут "Фірма", то, з огляду на особливості подання даних про організацію, розробник однозначно визначить необхідність подання даних у вигляді тестової рядка, що містить, як мінімум, найменування організації, а додатково - ще й організаційно-правову форму (наприклад, ТОВ "Чайник "). Звичайно, навіть в даному простому прикладі нс існує однозначності в розумінні того, як конкретні дані повинні бути представлені, але характеристику "Тип даних" визначити можливо, що формує більш чітке розуміння використовуваної структури даних.

Для атрибута "Фірма" уявлення однозначне, але для деяких атрибутів в документах не завжди можна однозначно визначити тип даних. Наприклад, розглянемо атрибут документа "Всього". Цей атрибут, якщо не знати особливостей заповнення документа "Товарний чек" та правил подання фінансової інформації в підсумковому рядку, може бути представлений будь-яким з двох типів даних: текстовим рядком або дійсним числом з двома знаками після десяткової коми. Варто звернути увагу па опис числового типу даних з даного атрибуту. Він представляється досить великим набором характеристичних особливостей, що дозволяє точно зрозуміти правила і форму представлення даних. У деяких СУБД для відображення фінансової інформації використовується грошовий тип даних, який є похідним типом з дійсного типу даних із заданою точністю. Зазвичай значення атрибута суми звично записати таким числовим значенням (наприклад, "25 637,54").

Однак для фінансових документів є правило в предметної області про те, що підсумкові суми повинні записуватися символьним значенням (наприклад, двадцять п'ять тисяч шістсот тридцять сім карбованців 54 коп.). Тут використовують саме тип даних текстового рядка, з огляду на необхідність використання символів алфавіту з включенням цифрових символів. Забігаючи трохи наперед, варто сказати, що подібне уявлення даних документа зазвичай не зберігається в базі даних, представляється числовим значенням, а відображення в друкованому або електронному документі у вигляді текстового рядка здійснюється на підставі програмних правил текстового подання числового значення. Таким чином, розуміння предметної області дозволило більш точно визначити правильність подання даних в документі і визначити тип даних, яким описується атрибут "Всього" в документі "Товарний чек".

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

 
<<   ЗМІСТ   >>