Biometric recognition & RFID: Last updated on
In non relational with flat-files;
In relational, RDBMS [ The following idea represents 1970s style of "very old" relational algebra, and relational calculus based relations ] approach; i.e. in 4GL, in Microsoft Access RDBMS (*.mdb) with VB front end dialog-interface: assuming that container DOT each database DOT each table DOT each column;
where VB front end dialog-interface textbox ← dynaset/dataset DOT view tables
where view tables from relations of Meta-table MT(1~N)
Data limitations accordance with allocation of OS's file size, NEC biometric scanned data size, RFID's 96bit EPC, ... ;
According to relational theory, Key must be unique. Human being's biometric genetic code is unique which can be scanned remotely, therefore RFID cannot be Key. Rule1
|Key||Primary Key||Foreign Key||Remark|
|NEC biometric scanned data1||itemized-data1 / class||Record1|
|NEC biometric scanned data2||itemized-data2 / class||Record2|
|NEC biometric scanned data3||itemized-data3 / class||Record3|
|NEC biometric scanned dataN-1||itemized-dataN-1 / class||RecordN-1|
|NEC biometric scanned dataN||itemized-dataN / class||RecordN|
System experts must decide how to manage/distribute Primary Key's 68G data for above meta-table MT1
|NEC biometric scanned data1||class1 / company||Record1|
|NEC biometric scanned data2||class2 / company||Record2|
|NEC biometric scanned data3||class3 / company||Record3|
|NEC biometric scanned dataN-1||classN-1 / company||RecordN-1|
|NEC biometric scanned dataN||classN / company||RecordN|
System experts must decide how to manage/distribute Primary Key's 16M data for above meta-table MT2
|NEC biometric scanned data1||company1 / EPC||Record1|
|NEC biometric scanned data2||company2 / EPC||Record2|
|NEC biometric scanned data3||company3 / EPC||Record3|
|NEC biometric scanned dataN-1||companyN-1 / EPC||RecordN-1|
|NEC biometric scanned dataN||companyN / EPC||RecordN|
System experts must decide how to manage/distribute Primary Key's 268M data for above meta-table MT3
For systems experts only: calculate the minimum possible and maximum possible data size to be stored, data size to be transacted, data size to be in memory, and ... ;
For database admin only: since 1 database contains N of tables; 1 table contains N of columns; 1 column contains N of fields; 1 table also contains N of rows; 1 row contains N of fields (basically, a row is a record); Each field contains data along with its column's data-type; Find a R-factor(Relation Factor) in base10, base2; And prove R-factor in OSI layers for thoughput gain; R-factor is very important, because common human being can only handle 5~7 steps ahead of thinking (i.e. average chess master can think 5~7 steps ahead before a move because human STM limits brunching factors ...), same logic in RDBMS while managing many databases, tables, columns, records, ... ; Due to human being's STM and LTM weaknesses, if someone/group manages/administrates any RDBMS without understanding R-factor, the database will be messy sooner or later because RDBMS are in GB, TB of data with more than 100 brunching factors ...
To be continue ... Security of RDBMS: Privilege, Profile, Role, ... ;
, 3GL, ...
In 2GL, data-type for each column (in Meta-table MT1~N) constraints recordable fields, thus 296 EPC must be developed under 128 bit system; If 128 bit system is not available, and then system experts must decide and adjust (least significant bit and most significant bit) the Primary Key column by separating tables ...;
|Length: 12 digit UPC; base10; CASE STUDY 1||Length: 96 bit EPC; base2 Dream 1|
CASE STUDY 1: Assuming that a supermarket's vendor print-out prompts the following record
UPC Description Dept Vendor No ... ... ... ...
060451010505 SUSHI CALIFORNIA ROLL 227 5356903 ... ... ... ...
Before scanning UPC by Fujitsu hand held IR scanner from salable item, receiver at loading dock insert Foreign Keys such as Vendor #, Dept #, Invoice #, ...; and then barcode from label must be scanned; after scanning items, Quantity and Cost are verified to make sure input data are correct; Notice that Foreign Keys binds the UPC data as Primary Key, and the Key is hidden in print-out; Same concept can be apply to implement Nutrition Systems ... in which mean, for each system such as Nutrition System, Clothing garment System, Home Appliances System, and etc. ... need Foreign Keys in relation; Developing such Foreign Key will provide recognition ... ;
Note: There are many supermarkets exist, thus supermarketA's scanned UPC data may not be the same as supermarketB's scanned UPC data, and so on; Thus, RFID cannot be Key, and Rule1 is correct.
Dream 1: a consumer comes to a supermarket to shop; location based supermarket's biometric recognition automatically recognizes who is coming to shop, and ready to scan for his/her retail cost; while shopping cart's RFID based TFT color display prompts accumulated(a=a+1; adder deploys distance-based calculation only) nutritional facts, accumulated total calories, %DV, and so on ...; when the consumer gets back home, and put the items into refrigerator; refrigerator RFID recognition system automatically adds into its current holding items with freshness, due date, and so on, and it's TFT color display prompts accumulated nutritional facts, accumulated total calories, %DV, and so on ...; On the other hand, if RFID scanners exist nationwide, and then its manufacturing cost, inventory holding cost, transportation cost, human resources cost, and etc. can be calculated not only in real-time, but also in run-time;
To be continue ...
SQL logic samples; According to relational theory, based on relational algebra, and relational calculus,
i.e. to get record(row): SELECT column FROM table(s) WHERE the column's conditional statement
For systems experts only: find the best possible relations among tables before/after distribution, thus lesser redundant (Never non-redundant) data will provide faster processing throughputs ... ;